APPLIC-0004-2008

医療・健康・福祉アプリケーション
基本提案書

財団法人全国地域情報化推進協会
アプリケーション委員会

2008 年 3 月
第2版

【 報 告 書 構 成 】

１

はじめに

２

医療・健康・福祉ワーキング 活動経過３

医療・健康・福祉ワーキング 構成員一覧「ＥＨＲ（健康領域）プロジェクト 基本提案書（第１版）」「ネットワークセキュリティプロジェクト 基本提案書（第１版）」「介護ネットワークサービスプロジェクト 基本提案書（第２版）」

1 はじめに（財）全国地域情報化推進協会では、多彩な ICT 利活用による高付加価値 ICT サービスを享受できる地域社会の構築を目指して、①自治体の抜本的改革や、自治体内外の多数の情報システムを連携させるための基盤構築の推進、②自治体で共通利用が可能な公共アプリケーション（防災、医療、教育等）の整備の促進、③地域情報化の基盤となる公共ネットワークの更なる整備や都道府県を結ぶ全国公共ネットワークの構築の推進等について
官民一体となって検討を進めているところである。
本ワーキングは、平成１７年１０月に当協会の前身となる全国地域情報化推進協議会が設立された際にアプリケーション委員会の新課題ワーキング（医療）として医療分野における地方公共団体向け検討活動をスタートさせ、年度末までの半年間でＩＴ新改革戦略を基点としながら、当該分野における地域での公共アプリケーションの普及・促進状況についての情報収集・整理とそれらの運用における課題と解決方法についての検討を行い、平成１８
年度の検討課題として①介護における自治体と民間とのネットワーク連携を実現するアプリ
ケーションの実現 ②医療・健診・介護など生涯健康データを電子的に有効活用するアプリ
ケーションの実現 ③これらのアプリケーションサービスを技術的に担保するセキュリティを確保した効率的なインフラ基盤の整備 の提言を行った次第である。
平成１８年度には母体組織は現行の体制に発展強化され、医療・健康・福祉ワーキングとして独立し主査に東京大学大学院の山本隆一准教授を迎えて本格的に検討を進める形とした。具体的には上記３つのテーマを検討するために専門のプロジェクトを立ち上げ、ＥＨ
Ｒ（健康領域）ＰＴとＮＷセキュリティＰＴでは調査結果の報告を中心とした検討報告書を、介護ＮＷサービスＰＴでは基本提案書（第１版）を作成したところである。 今年度は１８年度の検討結果を踏まえて、ＥＨＲ（健康領域）プロジェクトでは自治体が住民の健康情報をお預かりして一元管理を行うことにより新たなサービス提供を実現できる可能性についての提言を行い、ネットワークセキュリティプロジェクトでは災害発生時にＥＨＲ（健康領域）プロジェク
トにて提言するＥＨＲ情報の有効活用方法についての提言を行うこととした。また介護ＮＷ
サービスプロジェクトでは昨年度に現状の介護サービス業務について詳細な現状分析を行い取り上げた課題について、自治体ならびに介護サービス事業者にご検討いただきたい具
体的業務改善提案を行っている。私共の提案が住民満足度の向上や自治体業務の効率化に寄与することを切に願って止まない。
最後に本報告書の作成にあたり、ＡＰＰＬＩＣ会員の自治体、企業の皆様はもとより、厚生労働省や介護ソフト事業者等々大勢の皆様方から貴重なご意見や多大なアドバイスを頂戴したことに深謝する次第である。

2 医療・健康・福祉ワーキング 活動経過

活 動

開催日

活

動

内 容

・平成 19 年度 医療・健康・福祉ＷＧ活動計画案について審議
第１回ワーキング

H19.5.24

・各プロジェクトチームにおける活動計画案および募集状況について審議
全て議決
・各プロジェクトチーム活動状況について審議

第２回ワーキング

H19.7.30
議決・各プロジェクトチームの検討報告ならびにアプリケーション委員会への中間報告書(案)について審議

第３回ワーキング

H19.10.10
・各プロジェクトチームの今後の進め方について審議
全て議決
・各プロジェクトチームの各プロジェクトの検討状況ならびに提案書骨子第４回ワーキング

H19.12.11

について審議議決
・各プロジェクトチームの基本提案書作成状況について審議

第５回ワーキング

H20.1.30
議決・医療・健康・福祉ＷＧ基本提案書について最終審議
第６回ワーキング

H20.3.5
・医療・健康・福祉ワーキングの平成 20 年度の進め方について審議

3 医療・健康・福祉ワーキング 構成員一覧
平成 20 年 3 月 13 日現在
構 成 員 名 称

役 職

秋田県

副主査

京都府

副主査

長野県

副主査

和歌山県

副主査

千葉県市川市副主査

東京都中野区

副主査

東京都三鷹市副主査

島根県松江市副主査

秋田県横手市副主査

野津 勤（財団法人理工学振興会）
独立行政法人情報通信研究機構
ＮＰＯ法人医療ネットワーク情報センター
株式会社内田洋行
株式会社エスビーエス情報システム
ＮＥＣネッツエスアイ株式会社
エヌ・ティ・ティ・コミュニケーションズ株式会社
株式会社エヌ・ティ・ティ・データ

副主査

財団法人加古川総合保健センター
株式会社コミューチュア
株式会社サイバーリンクス
シスコシステムズ株式会社
東芝ソリューション株式会社
日本電気株式会社
日本アイ・ビー・エム株式会社
日本オラクル株式会社
社団法人日本ケーブルテレビ連盟
東日本電信電話株式会社
株式会社日立製作所

副主査

株式会社日立中国ソリューションズ
富士通株式会社
株式会社富士通総研
マイクロソフト株式会社

副主査

松下電器産業株式会社
株式会社三菱総合研究所
山本 隆一（東京大学大学院情報学環 准教授）

主査

厚生労働省 医政局 研究開発振興課 医療機器・情報室

オブザーバー

厚生労働省 老健局 介護保険課

オブザーバー

総務省 情報通信政策局 地域通信振興課 地方情報化推進室

オブザーバー

総務省 総合通信基盤局 高度通信網振興課 情報流通高度化推進室

オブザーバー35 団体

医療・健康・福祉アプリケーション 情報連携図

生涯健康情報基盤（ＥＨＲ）
基本提案書

財団法人 全国地域情報化推進協会
アプリケーション委員会

2008 年 3 月
第 1.0 版

【目次】
１

２

３

４

５

６

はじめに...................................................................................................................................................................... 1
１．１

本書の目的................................................................................................................................................. 1

１．２

検討の背景................................................................................................................................................. 1

１．３

活動経過 ..................................................................................................................................................... 2

生涯健康情報基盤（ＥＨＲ）の必要性と効果................................................................................................ 4
２．１

ＥＨＲを取り巻く外部環境 ...................................................................................................................... 4

２．２

課題の明確化と優先度設定................................................................................................................ 7

２．３

生涯健康情報基盤の定義と実現するサービス概要 ...............................................................13

２．４

想定効果 ...................................................................................................................................................17

２．５

想定効果創出に向けた目標指標の設定 .....................................................................................19

基本要件定義と実現方式の策定...................................................................................................................20
３．１

情報活用全体像と基本要件ヒアリング結果 ...............................................................................20

３．２

生涯健康情報の対象範囲の策定...................................................................................................25

３．３

生涯健康情報を扱うシステム間インターフェイスの標準様式..............................................31

３．４

方式策定 ...................................................................................................................................................34

３．５

セキュリティ概要設計 ...........................................................................................................................37

導入推進体制の策定と導入計画...................................................................................................................41４．１

導入推進体制の策定...........................................................................................................................41４．２

導入計画 ...................................................................................................................................................42４．３

導入予算・維持運営予算の項目策定............................................................................................43

４．４

先行導入計画における留意事項 ....................................................................................................44

運用設計..................................................................................................................................................................45５．１

運用組織と体制について....................................................................................................................45

５．２

運用継続性に関する検討...................................................................................................................47

評価・改善の方法 （目標指標のモニタリングと改善案の検討）........................................................49
６．１ 評価体制..........................................................................................................................................................49
６．２ 評価指標のモニタリング............................................................................................................................50
６．３ 改善方法...........................................................................................................................................................53

７

平成２０年度に向けて.........................................................................................................................................55

ＥＨＲ（健康領域）プロジェクト 構成員一覧.........................................................................................................56

１ はじめに

１．１ 本書の目的（財）全国地域情報化推進協会の事業内容の１つに｢自治体で共通利用が可能な公共アプリケー
ション（防災、医療、教育等）の整備の促進｣がある。この活動の一環として、本書は、医療・健診・介護・福祉など生涯健康データを電子的に保存・有効活用するための「生涯健康情報基盤（ＥＨＲ）」に関する基本提案書（第１版・概要版）をまとめたものである。本書により、生涯健康情報基盤の有効性をご理解いただくと共に、今後の住民向け健康情報活用サービスのあり方を検討する際の一助としてご活用いただければ幸いである。
本書は、平成１８年度の「ＥＨＲ（健康領域）プロジェクト検討報告書」の調査・分析結果を踏まえ、自治体向けの基本提案書（第１版・概要版）としての位置づけで、当協会の医療・健康・福祉ワーキ
ングＥＨＲ（健康領域）プロジェクトが中心となってまとめたものである。
少子高齢化の急速な進展に伴い、自治体を取り巻く環境は激しく変化しており、住民向けの保健
医療福祉サービスにおける諸課題解決の一つの方向性として、生涯健康情報基盤を提案するものである。誤解を避けるために、最初に本書の主旨を補足しておきたい。それは、健康分野のすべてのサービス種類、すべてのサービスレベルを自治体単独に押しつけようというものではなく、必要最低限の核（コア）となる土台整備を地域住民の健康情報保持者である自治体に期待し提言する主旨と考えていただきたい。土台になる核の意味で、「基盤」という用語を使用した。自治体と地域の保健医療福祉サービス団体・機関、民間事業者等とが協調、連携の基に次世代の包括的な保健医療福祉サービスの構築に取り組まれることを期待する。

１．２ 検討の背景
自治体を取り巻く環境は、労働人口の都市集中化と過疎化、地方分権の進展、個人情報保護と行政手続きの透明化、住民の価値観の多様化など大きく変化しており、住民サービスにおいて「個」を意識したサービスの質的向上が求められている。この環境の中で、２００５年３月の「地域における情報化の推進に関する検討会（総務省）」では、高付加価値ＩＣＴサービスを享受できる地域社会を目指して、「地域情報プラットフォームの開発」、そして「地域を越えて共通する公共アプリケーションの展開」が最終報告書として提言されている。その後、保健医療福祉分野に係わる政府の取り組みとして、２００６年１月の「ＩＴ新改革戦略」で、「ＩＴによる医療の構造改革〜レセプト完全オンライン化、生涯を通じた自らの健康管理〜」の方針が打ち出され、２００６年６月成立の｢医療制度改革関連法｣により、生活習慣病予防としての特定健診・特定保健指導制度の導入、医療機能の分化・連携の推進
による切れ目のない医療の提供を目指す医療計画の見直し等が２００８年４月から施行となった。この新制度への自治体としての対応が急務となっている。
一方、近年ではインターネット等を使用したセキュリティが確保された通信技術や、ＩＰネットワーク
1
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

上のＷｅｂシステムのような外部へ開かれた処理技術等の進展により、情報システムは相互に接続されることを前提として構築されるようになってきている。この技術革新によって自治体にとっての可能性は飛躍的に拡大した。保健医療福祉分野におけるシームレスな情報サービスなどの高付加価
値ＩＣＴサービスを行政・民間連携のもと住民等に提供する新たな目標を追求することが可能となっている。
以上の住民ニーズおよび社会ニーズに応えるためには、これまでのように個別自治体による取り組みに止まらず、自治体の枠を越え、住民、保健医療福祉サービス団体・機関、民間企業等の地域情報化を担う他の様々な主体との連携も視野に入れた取り組みが重要と考え、当協会の医療・健康・福祉ワーキングでは自治体向けに「生涯健康情報基盤（ＥＨＲ）」の基本提案書を作成することとした。
本基本提案書では、まず「生涯健康情報基盤（ＥＨＲ）」の必要性とその効果について述べ、次にその実現方法（情報の範囲、様式、方式、導入計画、運用、評価・改善）について述べている。実現方
法は、それぞれの地域、自治体の特性に応じて多様な実現手段があるため、本提案書では推奨モデルを記述することとした。推奨モデルは広域化と低コストのためにある一定の標準を活用することとした。各地域および自治体では、特徴および独自性を反映して、本推奨モデルにアドオンあるいは変更して活用していただきたい。本推奨モデル自体、定期的に見直して改版する予定である。

１．３ 活動経過
年度始めの活動計画書に基づき、先進自治体との共同研究、視察、および事例発表の結果を踏
まえ、生涯健康情報基盤（ＥＨＲ）の基本提案書（第１版・概要版）を作成した。
表 １-１ ＥＨＲ（健康領域）プロジェクト 活動状況
活動

日付

活動内容

第１回ＰＴ開催

2007 年 7 月 6 日

・2007 年度活動計画の報告、共同研究先公募結果の報告・事例発表「秋田県のＩＣＴを活用した健康推進施策」

共同研究先ヒアリング（第１回）
第２回ＰＴ開催

2007 年 7 月 31 日〜

8月2日

2007 年 8 月 3 日・ヒアリング先 ： 秋田県内の地方自治体３カ所、健診団体２
カ所、医療機関１カ所・事例発表「和歌山県における医療保健分野の ICT の取り組
み」共同研究先ヒアリング（第２回）
第３回ＰＴ開催

2007 年 8 月 22 日〜

8 月 23 日

2007 年 9 月 21 日

・ヒアリング先 ： 秋田県内の医師会２カ所、健康保険組合２
カ所、審査機関１カ所・事例発表「加古川総合保健センターのＩＣＴの取り組み」

・共同研究先ヒアリング結果の報告
第４回ＰＴ開催

2007 年 9 月 28 日

・アプリケーション委員会中間報告案の検討
・普及啓発活動に使用する発表資料の検討

2
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

活動

日付

活動内容

共同研究先視察2007 年 10 月 2 日

・視察先2007 年 10 月 4 日

療情報センター加古川総合保健センター、加古川地域保健医

普及啓発活動2007 年 10 月 12 日 ・「地域 ICT 未来フェスタ in あおもり」講演

第５回ＰＴ開催

2007 年 10 月 25 日 ・アプリケーション委員会、ＷＧの指摘事項の報告
・基本提案書の構成案の検討

第６回ＰＴ開催

2007 年 11 月 12 日 ・基本提案書の概要案の検討（WG 主査 参加）

普及啓発活動2007 年 11 月 14 日 ・「全国地域情報化推進セミナー2007in 岡山」参加

第７回ＰＴ開催

2007 年 12 月 6 日

・基本提案書案の検討

第８回ＰＴ開催

2008 年 1 月 22 日

・基本提案書案のレビュー

第９回ＰＴ開催

2008 年 2 月 13 日

・基本提案書案の最終レビュー

普及啓発活動2008 年 2 月 26 日

・富山「地域医療情報ネットワーク講演会」講演

第 10 回ＰＴ開催

2008 年 2 月 29 日

・アプリケーション委員会報告内容の確認

普及啓発活動2008 年 3 月 22 日

・秋田「健康福祉 ICT まるごと安心シンポジウム 2008」講演《参考文献》
・

ＩＴ新改革戦略（平成１８年１月１９日） 内閣官房
http://www.kantei.go.jp/jp/singi/it2/kettei/060119honbun.pdf

・

重点計画-２００７（平成１９年７月２６日） 内閣官房
http://www.kantei.go.jp/jp/singi/it2/kettei/070726honbun.pdf

・

医療分野におけるＩＣＴの利活用に関する検討会報告書 総務省
http://www.soumu.go.jp/s-news/2006/060418̲1.html#hp

・

医療・健康・福祉アプリケーション基本提案書（第１版） 全国地域情報化推進協議会
http://www.applic.or.jp/APPLIC/2007/APPLIC-0004-2007/

・

保健医療分野の情報化に向けてのグランドデザイン 厚生労働省
http://www.mhlw.go.jp/shingi/0112/s1226-1a.html

・

特定健康審査・特定保健指導の円滑な実施に向けた手引き 厚生労働省
http://www.mhlw.go.jp/bunya/shakaihosho/iryouseido01/info03d.html

・

医療情報システムの安全性管理に関するガイドライン（第２版） 厚生労働省
http://www.mhlw.go.jp/shingi/2007/03/dl/s0301-12a.pdf

・

IT による地域活性化等緊急プログラム骨子 内閣官房
http://www.kantei.go.jp/jp/singi/it2/kettei/071107honbun.pdf

3Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

２ 生涯健康情報基盤（ＥＨＲ）の必要性と効果

２．１ ＥＨＲを取り巻く外部環境
個人の健康および安全・安心へのニーズの高まりから、種々の制度改革、施策が進展しており、
生涯健康情報基盤（ＥＨＲ）構築のための諸環境は、日々整備されつつある。ＥＨＲを取り巻く環境として、以下に５つの展開中の施策に注目する。
(１) レセプト申請のオンライン化(２) 特定健診制度(３) 健康情報活用基盤の実証事業(４) 社会保障カード（仮称）の検討(５) 医療情報の外部保存
これらの流れの概要について以下に述べる。

（１） レセプト請求のオンライン化
厚生労働省では、昨年度からレセプト請求のオンライン化を開始し、平成２２年度末までにオンライン化を完了し、平成２３年度以降は原則オンライン請求の方針を打ち出している。マイル・ストーン
として、調剤薬局を平成２０年度末まで、病院を平成２１年度末まで、診療所を平成２２年度末までとしている。調剤薬局については、「レセプトコンピュータの導入」および電子媒体による保険請求を行う「レセプト電算処理システム」が普及しており、ネットワーク化によってオンライン請求が進展すると考えられる。医療機関は、レセプトコンピュータの導入率は高率であるが、レセプト電算処理シ
ステムの普及が約２０％程度であり、レセプト電算処理システムを進めつつ、オンライン化が必要である。歯科医療機関については、レセプトコンピュータの導入はある程度進んでいるが、レセプト電算処理システムがこれまで未着手のため、まずレセプト電算処理システム化が喫緊の課題である。
レセプトのオンライン請求は、請求元機関から、審査支払機関、医療保険者までが一気通貫で電子化されるため事務手続きの効率化になるだけではなく、保険請求データの電子化により貴重な診療情報の蓄積と疫学統計等が可能となる。
つまり、レセプト自体には、検査結果以外の病名、検査項目、処方薬等の診療内容を判断するのに必要な情報がすべて含まれており、これを使えば生活習慣病や慢性疾患に関する患者の病歴の把握や治療内容の推移をチェックすることが可能である。このため、レセプトのオンライン化によって保険者の側で被保険者の健康状態の動向把握や適切な保健指導をするための情報を得ることができる。今後は、診療に役立つ科学的根拠データづくりや疾病管理につなげるため、電子化されたレセプトデータの蓄積と分析に期待が高まっている。

4
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

（２） 特定健診制度
特定健診制度は、生活習慣病予防の徹底を図るため、平成２０年度から保険者に対して４０歳から７４歳までの全国民を対象に「特定健診」と「特定保健指導」を義務付けた。この制度の政策目標の一つ目は、健診受診者、特に被用者保険の被扶養者（組合健保等の社会保険の配偶者等）の健診受診率向上にある。二つ目は、平成２０年度から平成２７年度までに糖尿病等の生活習慣病
有病者・予備群を２５％減少させることである。
市町村自治体は、国民健康保険、国保の保険者であり、健診や保健指導の実施者でもある。市
町村自治体は、特定健診制度によってその地域で複数の制度に基づいた健診、例えば特定健診とがん検診を同時に共同実施することになる。自治体における各種健診と法制度を【出典：特定健康診査・特定保健指導の円滑な実施に向けた手引き 厚生労働省】 図 ２-１に示す。

【出典：特定健康審査・特定保健指導の円滑な実施に向けた手引き 厚生労働省】
図 ２-２ 市町村自治体における各種健診と法制度
特定健診の結果、一定の基準を超えている受診者に対して保険者は保健指導を行わなければならない。この対象者の選定を階層化といい、「情報提供」（基準以下）、「動機付け支援」、「積極的支援」がある。
表 ２-１ 特定保健指導の対象者（階層化）
腹囲≧８５ｃｍ（男性）

追加リスク①血糖 ②脂質 ③血圧④喫煙歴

２つ以上該当≧９０ｃｍ（女性）

１つ該当

上記以外で

３つ該当

あり

対象
４０〜６４歳
積極的支援

６５〜７４歳

動機付け支援なし
積極的支援

動機付け支援5
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

ＢＭＩ≧２５

２つ該当

あり
なし

１つ該当
（注）喫煙歴の斜線は、階層化の判定が喫煙歴の有無に関係ないことを意味する。
【出典：特定健康審査・特定保健指導の円滑な実施に向けた手引き 厚生労働省】
特定保健指導の対象者選定における優先度を考慮した基本的考え方を表 ２-１に示す。
特定健診制度は、健診や保健指導の結果情報、請求情報は標準的電子フォーマットでの提出を求めている。標準的電子フォーマットは、厚生労働省の研究班成果としてＨＬ７ＣＤＡ Ｒ２Ｌ３規格に準拠したＸＭＬ記述となっている。この詳細は、「健診データの電子的管理の整備に関するホームページ」（ＵＲＬはｈｔｔｐ：／／ｔｏｋｕｔｅｉｋｅｎｓｈｉｎ．ｊｐ）に記載されている。
自治体では、がん検診等の特定健康審査の項目以外も追加して健診を共同実施することが想定され、健診機関、および代行機関は一人の受診者の費用を項目単位で請求先（自治体等の担当部門、あるいは保険者）を分けて請求する必要がある。従来の健診は、健診単位で包括的に請求していたため、このような項目単位に分別して請求書を発行するシステムは存在しなかった。このように、特定健診制度では、報告書等の電子的な提出や複雑な請求書を作成・送信できる効率的なデータ処理システムと健診・保健指導機関、代行機関、および保険者間のネットワーク化が必須になっている。厚生労働省研究班では、特定健診制度の発足に併せて小規模健診･保険指導機関が特定健診のＩＴ化対応できるよう一部基本機能についてフリーソフトウェアを専用のホームページで公開している。

（３） 健康情報活用基盤の実証事業
総務省、厚生労働省及び経済産業省の３省連携のもと、個人の健康情報の活用に資する健康情報活用基盤の構築に向けた実証を平成２０年度から行う計画である。
具体的には、生涯にわたる健康情報を個人が電子的に入手し自らの健康管理等に活用するとともに、医療機関等がその健康情報を活用し他の医療機関との連携等による継続性ある医療の提供を行うための実証等を行う。

（４） 社会保障カード（仮称）平成１９年９月に設置された「社会保障カード（仮称）の在り方に関する検討会」（厚生労働省）において、社会保障カード（仮称）の導入に向けて、まずは、当該カードに係る基本的な制度設計等について検討がなされてきた。平成２０年１月２５日に「社会保障カード（仮称）の基本的な構想に関する報告書について」が発表された。その基本的な構想の４つの考え方について、以下に列挙する。
①まずは、年金、医療、介護分野を対象に本カードを導入し、利用者の利便性を向上させることとするが、将来的には、ＩＣカードの特性を活かして、他の社会保障分野への用途拡大が可能となるような仕組みとする。
6
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

②カードの導入によって、利用者の利便性を向上させるだけではなく、保険者、医療機関や介護サービス事業者等のサービス提供者、行政機関の事務効率化にも資する仕組みとする。
③自らの年金記録、特定健診結果やレセプト情報等の情報が一元的に管理され、プライバ
シーが侵害されるのではないかという不安が極力解消されるような仕組みとする。また、カードを紛失した場合や盗難にあった場合でも大丈夫なのかといった点も含め、様々な懸念や不安が極力解消されるよう、具体的な仕組みの説明に努め、利用者の理解が得られるようにする。
④カードの導入に当たっては、レセプトオンライン請求、住民基本台帳カード発行、公的個人認証サービス、電子私書箱等の既存の仕組みや関連する仕組みを最大限に活用し、可能な限り、追加費用を抑える仕組みとしつつ、カード導入費用及び毎年の運営費用に見合うだけの効果が生み出されるような仕組みとする。
詳しくは、ホームページ http://www-bm.mhlw.go.jp/shingi/2008/01/s0125-5.html を参照。

（５） 医療情報の外部保存
平成２０年２月７日開催の厚生労働省「医療情報ネットワーク基盤検討会」（第１８回）において、①医療情報の取り扱いに関する責任およびその在り方、②医療情報の外部保存を受託する機関の選定基準および情報の取り扱いに関する基準等が審議された。この審議結果は「医療情報シス
テムの安全管理に関するガイドライン第３版（案）」として取りまとめられ、国民のパブリックコメントを受けて制定される運びとなっている。
本ガイドラインにより、医療機関の他、行政機関でしか認められていなかった医療情報の外部保存が、一定の条件を満たせば、民間での外部保存が可能となる。これにより、行政機関が安全かつ強固なセキュリティ環境を独自で構築しなくても、基準を満たす民間の外部保存事業者等にアウトソーシングすることにより、財政的、運用的により効率的に医療情報を外部保存する環境が整う見込みである。
詳細は、「医療情報システムの安全管理に関するガイドライン 第３版」を参照されたい。

２．２ 課題の明確化と優先度設定（１） 保健・医療・介護・福祉分野における地方自治体が抱える課題
保健・医療・介護・福祉分野における自治体の課題を検討するにあたり、大きく都道府県と市町村に分けて、役割と課題について整理する。ここでの市町村は、政令指定都市を除く一般的な市町村についてモデル的に記述している。

① 都道府県の役割と課題
ア）都道府県の役割
都道府県の保健・医療・介護・福祉分野における役割は、数多くあるが、本節では、特に注視すべき事項のみを挙げる。そのため、本節で挙げているものは、都道府県の役割す7
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

べてでなく、一部分である。
○ 子育て支援、児童福祉、生活保護、障害福祉および高齢者福祉の充実。
○ 保健所の設置、伝染病予防、食品衛生の管理等の実施。
○ 都道府県健康増進計画、地域ケア整備計画、医療費適正化計画を市町村との連絡協議を行うことによる策定。
○ 地域における健康危機管理体制の整備。
○ 医療計画、病院・医療法人の許認可の適正な実施。

イ）都道府県の課題
上述の都道府県の役割を元に、都道府県が行政サービスの提供を円滑かつ効果的に行うにあたって重点的に解決すべき課題について以下に示す。
○ 科学的根拠に基づいた地域保健を推進する必要があると共に、そのために地域の保健、医療情報の把握と地域住民へ啓発、医療機関や関連団体との連絡調整を行う必要がある。
○ 医療計画（がんや糖尿病等の４疾病及び救急医療や災害時における医療等の５事業、医療資源の偏在、医師、看護師不足）、医療費適正化計画、介護保険事業支援計画、
老人保健福祉計画、障害者計画等、地域ケア体制整備構想の企画及び調整の機能を強化する必要がある。
○ 地域保健対策に係る人材の確保及び資質の向上に向けた対策が必要である。
○ 保健、医療、福祉の連携の下で最適なサービスを提供するための総合調整機能を提供
し、市町村の求めに応じて、専門的及び技術的支援を行う必要がある。
○ 二次医療圏における保健、医療、介護、福祉サービスの社会資源を有効に活用できる
制度・システムの構築を図るため、検討協議会の設置などの対策を講じる必要がある。

② 市町村の役割と課題
ア）市町村の役割
市町村の保健・医療・介護・福祉分野における役割は、都道府県と同様に数多くあるが、本節では、特に、注視すべき事項のみを挙げる。そのため、本節で挙げているもの
は、市町村の役割のすべてでなく、一部分である。
○ 生活保護、児童福祉および高齢者福祉の充実。
○ 国民健康保険、介護保険、後期高齢者医療広域連合の窓口業務等の適正かつ円滑な実施。
○ 衛生行政の実施（予防接種、埋火葬の許可等）。
○ 市町村健康増進計画、市町村老人保健計画、介護保険事業計画の策定を都道府県との連絡調整を行うことによる策定。
○ 特定健診・保健指導実施計画の策定及び事業実施。
8
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communicationイ）市町村の課題
上述の市町村の役割を元に、市町村が行政サービスの提供を円滑かつ効果的に行うにあたって重点的に解決すべき課題について以下に示す。
○ 地域保健対策における生活者個人の視点の重視した施策の実施が必要である。
○ 住民の多様なニーズに対応したきめ細かなサービスの実施が必要である。
○ 身近で利用頻度の高い保健サービスが一元的に提供されるよう市町村保健センター等の拠点を整備する必要がある。
○ 地域の特性を生かした保健と福祉のまちづくりが必要である。
○ 事業の将来的な見通しの下に保健師、管理栄養士等の地域保健対策に従事する専門
技術職員の計画的な確保を推進する必要がある。
○ 市町村保健センター等の保健活動の拠点、保健所、福祉事務所等の行政機関及び老人介護支援センター、医療機関、薬局、社会福祉施設、介護老人保健施設、訪問看護
ステーション等の施設を結ぶ地域の特性に応じたネットワークを整備する必要がある。
○ 特定健診・保健指導、母子保健事業、労時保険事業等の各種保険事業を円滑に実施する必要があり、医療機関および保険者協議会等の関連団体との連絡・調整を行う必要がある。
○ 現行の基本健診等の実施部署（例えば、健康増進課）と、特定健診・特定保健指導の責任部署（例えば国民健康保険課）間で連係して、住民健康情報を共有しつつ特定健診事業を進める必要がある。また、特定保健指導に際して、医療機関での診療状況等の情報を得ることで、適切な指導を実施することができる。一方、医療機関においても、初診外来の場合、医師はそれまでの患者の健康診断の情報を得たうえで診察に臨みたいという実情がある。
○ 住民の適正な医療費負担、介護費負担の条件のもとで、医療介護サービスを維持する必要がある。そして、国民健康保険、介護保険の給付金の増大への対処が必要である。
○ 衛生行政の実施（予防接種の実施等）に対応する必要がある。
○ 住民からの透明性への要望、具体的には自己のカルテやレセプトの開示への取り組みが必要であり、更にセカンドオピニオンやインフォームドコンセント等の多様なニーズへの対応が必要である。
○ 災害・救急時における迅速な搬送・治療（早期発見・早期搬送・早期治療の実現）。
○ 都道府県の策定する計画との調整を行い、市町村健康増進計画、介護保険事業計画の策定を行う必要がある。

9
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

（２） ⅠＣＴ活用面からの優先度設定① 課題の整理「２．２（１）保健・医療・介護・福祉分野における地方自治体が抱える課題」で都道府県、市町
村別に抽出された課題を、本節で整理する。
都道府県
＜情報＞
科学的根拠に基づく地域保健の推進
地域の保健医療情報の把握＜人＞
市町村への専門的、技術的支援
地域保健対策に係る人材の確保育成
地域住民への啓発＜その他＞
各種計画の企画及び調整
市町村及び医療機関、保険者協議会等の関連団体との連絡調整

市町村
＜情報＞
健診情報の医療と保健のシームレスな
情報共有

住民ひとり一人の健康情報に基づいた保健医療サービスの提供
データに基づいた保健医療介護施策の策定
専門的な知識に基づいた施策の円
滑な実施
行政及び医療機関、保険者協議会
等の関連団体との連絡調整

人材確保・育成

健診情報の時系列的な情報管理
情報開示による安心・安全な医療ｻｰﾋﾞｽ＜人＞
制度改正による役割・体制の見直し＜金＞
国民健康保険、介護保険の支出の抑制
患者の適正な医療費負担の下のサービス

生活習慣病対策の定着と成果の管理
高齢化社会に対応した健康情報の蓄積
健診及び医療・介護情報の共有と
公開

＜その他＞
各種計画の企画及び調整
都道府県との連絡調整
福祉行政、特定健診・保健指導、各種保険事業、衛生行政等の実施
医療機関、保険者協議会等の関連団体との連絡調整災害・救急時における迅速な搬送・治療

図 ２-３ 課題点の整理
10
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

② ＩＣＴ活用面からの課題の優先度「①課題の整理」で検討した内容を踏まえ、保健・医療・介護・福祉分野における課題を「質の向上」と「効率性」の 2 つに視点で優先度を設定する（「図 ２-４ 優先度設定」参照）。各指標については、以下の通り。
○ 質の向上： 当該課題を解決することにより、保健・医療・介護・福祉分野のサービスの質的向上が期待されるか否かにより、評価する。
○ 効率性： 当該課題を解決することにより、保健・医療・介護・福祉分野のサービスが効率的になるか否かにより、評価する。

高い

サービスの﹁
質の向上﹂

エリアＢ

エリアＡ

データに基づいた保健医療介護施策の策定

住民ひとり一人の健康情報に基づいた保健医療介護サービスの提供

高齢化社会に対応した健康情報の蓄積
健診及び医療・介護情報の共有と公開
人材確保・育成
行政及び医療機関、保険者協議会等の関連団体との連絡調整

生活習慣病対策の定着と成果の管理

エリアＤ

エリアＣ
専門的な知識に基づいた施策の円滑な実施

低いサービスの「効率性」

低い

高い

図 ２-４ 優先度設定
なお、４分割された各エリアについては、以下の解説を参照。
表 ２-２ 各エリアの解説
エリア

優先度

備考
解決することによってサ―ビスの「質の向上」とサービスの「効率性」が高くなる課題であり、優先度が最も高い。
エリアＡに続き、優先度が高いエリア。保健・医療・介護・福祉分野では、サービスの「効率性」よりも「質の向上」を重視するという傾向から、エリアＢが優先度２である。
サービスの「質の向上」にはそれほど影響はないが、サービスの「効率性」が高くなるもの。
他の課題と比較して、早急に対応しなくても良い課題であるか、若しくは他の課題を解決することにより、副次的に解決するもの。もしくはＩＣＴ活用の効果とは繋がらないもの。

エリア

Ａ

優先度１

エリア

Ｂ

優先度２

エリア

Ｃ

優先度３

エリア

Ｄ

優先度４

11
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communicationア）エリアＡ
最も優先度が高いと考えられるエリアＡには、特定健診で得られた健診情報の診療への活用などの「住民ひとり一人の健康情報に基づいた保健医療介護サービスの提供」、「健診及び医療・介護情報の共有と公開」や、健診の受診率向上、保健指導の効果の向上が期待できる「地域住民の健康意識の向上」と「生活習慣病の定着と成果の管理」が位置づけられる。

イ）エリアＢ
エリアＢにおいては、行政が施策や事業を行うにあたっての各種計画策定における科学的根拠データの蓄積と、施策の有効性や事業の評価を定量的に行える「データに基づいた保健医療介護施策の策定」、医療費適正化計画、介護施策等に効果が期待される「高齢化社会に対応した健康情報の蓄積」や、医師、看護師、保健師等の確保や医療・保健･介護分
野での計画策定に必要な自治体職員の能力向上を目指す「人材確保・育成」が位置づけられる。

ウ）エリアＣ
エリアＣにおいては、行政が多様化する住民の課題やニーズを迅速かつ効果的に把握・分析し、施策の策定や事業の実施が可能となる「専門的な知識に基づいた施策の円滑な実施」が位置づけられる。

エ）エリアＤ
保健・医療・介護・福祉分野における課題のほとんどは早急に対応すべきものが多く、「サービスの「効率性」」「サービスの「質の向上」」両視点において、共に優先度が低いものはないと考えられる。

③ 総括「（２）ⅠＣＴ活用面からの優先度設定」で検討した内容を踏まえると、早急に以下の課題を解決すべきだと言える（「図 ２-４ 優先度設定」内の赤枠部分）。
○

住民ひとり一人の健康情報に基づいた保健医療介護サービスの提供○

健診及び医療・介護情報の共有と公開○

データに基づいた保健医療介護施策の策定○

高齢化社会に対応した健康情報の蓄積○

生活習慣病対策の定着と成果の管理

上述、課題を解決するためには、「個人の健康情報を長期にわたり収集し、コンピュータ処
理可能な形式で保存し利活用できるようにした仕組み」、つまり「生涯健康情報基盤」が必要であると言える。なお、生涯健康情報基盤については、「２．３生涯健康情報基盤の定義と実現するサービス概要」以降で解説を行う。
12
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

２．３ 生涯健康情報基盤の定義と実現するサービス概要
本節では、より具体的に「生涯健康情報基盤」の定義を述べ、続いていろいろな利用シーンにおける「生涯健康情報基盤」の使われ方を示してサービス概要を述べる。

（１） 生涯健康情報基盤の定義「生涯健康情報基盤」とは、個人の健康情報を長期にわたり収集し、コンピュータ処理可能な形式で保存し利活用できるようにした仕組み全体である。従って、単なるデータベース、コンピュータシ
ステムではなく、運営理念、運営目標、運用体制、運用管理規約等も含んだ人とコンピュータシステ
ムとの融合体を指す。当然のことながら、個人情報保護法を担保するセキュリティの仕組みを兼ね備えている。
生涯健康情報基盤で取り扱う個人の健康情報は、①健診・保健指導情報 ②レセプト情報（診療報酬請求明細書） ③診療情報（要約情報） ④介護・福祉情報などである。

生涯健康情報基盤
生涯健康情報基盤システム

運営理念

情報の維持・閲覧

運営目標

匿名化
情報

健診

利用施設

医療
自治体

運営体制

介護
情報の登録

運営管理規則委託

運営資金

住民（個人）
地域包括
支援セン
ター等

医療機関

診療

介護など

医療保険者

健診・レセプト

図 ２-５ 生涯健康情報基盤の定義
利活用の視点から、生涯健康情報基盤は、｢生涯利活用できる健康情報」と｢全国規模で分析可
能な健康情報｣の２つから構成され、前者は個人を特定し個に応じた保健医療福祉サービスの提供に寄与する情報環境であり、後者は匿名化された情報でサンプル規模ではなく全数で保健医療福祉サービスの状況が分析可能な情報環境である。｢生涯利活用できる健康情報｣は、住民が自分の生涯の保健医療福祉情報を自らが管理し、自らの健康管理・疾病予防・治療・介護等の場面で活用する情報環境で、住民が自らの意思で利用の選択が可能なシステムである。｢全国規模で分
13
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication析可能な健康情報｣は、行政機関・医療機関等で管理され、地域の実情に適した保健医療福祉分
野の行政計画策定や保健医療福祉サービスの質の向上などに活用される。

【出典：ＩＴ戦略本部 医療評価委員会資料】
図 ２-６ 記名データと匿名データの利活用イメージ
情報管理センター
匿名ＤＢ

診療情報
中核病院

生涯健康
医療情報
ＤＢ

クリニック

遠
隔
診
療

生涯健康情報基盤

診療情報

へき地診療所

健診機関
健診情報
ﾚｾﾌﾟﾄ情報

医療

薬

保健所

保健福祉

介護・福祉

（投薬情報）

薬局

人間ドッグ

情報セキュリティ、
ネットワークセキュ
リティの確保服薬履歴

地域包括支援センター

介護（予防）
サービス事業者

給付管理票
ﾚｾﾌﾟﾄ情報

図 ２-７ 住民が生涯健康情報基盤を利活用するイメージ（２） 実現するサービスの策定にあたり実現するサービスの検討にあたり、自治体向けの住民サービスを主眼とし、保健・医療・介護・福祉の横断的サービスを可能とする情報基盤システムの構築を狙いとした。その基盤部分は、欧米先進諸国で現在構築中の各種ＥＨＲシステムの最小共通部分（ミニマムセット）と一致する。
以下にサービス概要を記述するにあたり、最低限必須の「基本的サービス」と比較的に「高度な14
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

選択的サービス」との２タイプに分類して表現した。基本的サービスについては、生涯健康情報基盤システムのコアの部分であり、主に自治体に構築を期待する範囲であり、高度な選択的サービスについては、地域および自治体における方針により様々な形態が考えられるが、どちらかというと民間事業者の競争市場原理を生かした構築が望ましい部分である。

（３） 実現するサービス概要
利用目的を大きく３つに分類して、①住民向け健康情報サービス、②災害医療・救急医療におけるＩＣＴ支援サービス、③健康推進施策の策定、啓発活動支援サービス、とし以下にそのサービス概要を述べる。

① 住民向け健康情報サービス
このサービスは、生涯健康情報基盤の中心となるサービスであり、「いつでもどこでも必要な時に自身の健康情報を参照し、活用できる」機能を提供する。標準装備が望まれる基本サービスの範囲は、住民の健康情報、例えば健診・保健指導情報、医療情報（診療情報とレセプト情報）、介
護・福祉情報等の収集、維持、閲覧を行う機能である。
比較的に高度な選択的サービスとして、家庭で測定した個人の健康情報を家庭から登録し、その結果を契約関係にある保健師が観察し、適時、保健指導の助言を行う等の機能がある。
この基本サービスの利用シーンとして、以下のケースが考えられる。各利用シーンでの基本
サービス機能は閲覧であり、端末にはウェブ・ブラウザ等の情報参照ツールがあれば対応可能である。

ア）健診施設、保健指導施設において、利用者（受診者）の希望でこれまでの健康情報の内容を医療保健従事者に提示する。
イ）医療機関（病院、診療所、薬局）の受診に際し、利用者（患者）の希望でこれまでの健康情報の内容を医療保健従事者に提示する。
ウ）地域包括支援センター等で生活機能評価を受ける時、あるいはケアプランの作成を受ける際に、利用者の希望でこれまでの健康情報の内容を介護従事者に提示する。
エ）介護事業者において介護サービスを受ける際に、利用者の希望でこれまでの健康情報の内容を介護従事者に提示する。
オ）住民が個人の自己健康管理のために、自宅のパソコンから蓄積されている本人の健
康情報にアクセスし生活習慣に気をつける。
カ）自治体が国保保険者として、特定保健指導対象者の抽出時に加療中か否かの判断をするため、生涯健康情報基盤システムにアクセスする。
キ）自治体ががん健診等を実施する際に、自治体から委託された医療従事者が総合判
断時に生涯健康情報基盤システムにアクセスする。

15
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communicationク）自治体が住民サービスとして健康相談窓口を開設して、相談対応する場合に、生涯健
康情報基盤システムにアクセスして住民一人一人のデータに基づいて対応する。
ケ）自治体、および民間事業者が健康増進施設（健康運動教室、高齢者運動教室、運動
ジムなど）を運営する際に、利用者の希望でこれまでの健康情報の内容をトレーナ等に提示する。

② 災害医療・救急医療におけるＩＣＴ支援サービス
米国南部を襲ったハリケーン・カテリーナの被災時に、ニューオーリンズから避難した多数の住民の健康管理にＥＨＲがおおいに効果を発揮したと報告されている。水害、地震、風害、伝染病、事故、テロなどの災害時、および救急時には、平常時に利用できていた医療施設、自治体関
連施設等が利用できない環境となり、個人の健康情報のなかで最低限必要な情報に、現場の医療対応者がアクセスできることは非常に有益となる。また、２００７年度に当協会の防災ワーキン
グ、ＮＷセキュリティＰＴが三条市の協力で行った防災実証実験において、災害時の医師等の対応の際、日頃の服薬情報、アレルギー情報だけでも情報が参照できると非常に役立つという結果が報告されている。
従って、ここでの標準装備が望まれる基本サービスは、災害・救急時に最低限必要となる個人の健康情報を収集、維持、閲覧する機能である。
より高度な選択的サービスとしては、携帯電話を使用したモバイル閲覧機能、更には災害、救急時の処置等の実施情報を健康情報基盤システムに登録する機能がある。
医療・健康・福祉ワーキングのＮＷセキュリティプロジェクトでは、災害医療・救急医療での最低限必要となる医療情報の範囲、アクセス権限とセキュリティの課題、行政区域を越えた広域連
携の課題について検討中であるので、この報告書も合わせてご参照願いたい。

③ 健康推進施策の策定、啓発活動支援サービス
自治体における現状の課題の節でも述べたが、現在は健康施策の策定における現状把握と施策の効果測定が困難である。また、健康増進施策のポピュレーション・アプローチにおける説
得力ある根拠に基づいた啓発材料（健康ホームページ、健康ビデオなど）の作成が困難な状況にある。この事態から抜け出すためには、まず該当地域における保健医療福祉サービスの状況を定量的・経時的に把握することが必要となる。この要求に応えるものが本サービスである。
このサービスは、上記２つのサービス①、②が個人を特定し個に応じたサービスであるのに対し、地域のマスデータ（匿名化あるいは無名化データ）を対象とし、その地区の保健医療福祉
サービスの状況が把握可能となるデータを提供するサービスである。
従って、ここでの標準装備が望まれる基本サービスは、該当地域の保健医療福祉サービスの状況が把握可能となる匿名化あるいは無名化データを収集・維持・有資格者にデータ提供する機能である。
より高度な選択的サービスとしては、生涯健康情報基盤システムから提供されるデータをもとに分析・評価・作表する機能などがある。
16
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

２．４ 想定効果
本節では、前節を受け、「生涯健康情報基盤」を様々なシーンにおいて活用することによって、利用者がどのようなメリットを享受することができるのかについて幅広く考察する。

（１） 期待する効果
住民の健康情報を、本人からの委任により預かって蓄積・管理する「生涯健康情報基盤システ
ム」を構築し、その基盤を自治体や様々な機関が活用することにより、保健医療福祉分野における多様な課題の解決および新たな住民サービスの創出に効果を発揮することが期待される。
効果内容を基本と応用に大きく分類すると、基本的効果としては、今まで保存期間が限られており散逸してしまっていた個人の健康情報を生涯に亙って蓄積・管理でき、診療を受けるときや自己の健康管理に際していつでも必要な時に取り出せることである。また保険者間の移動において引き継がれていなかった情報の引き継ぎができることにより、居住場所や所属の移動があっても、情報の継続的な管理が可能となる。
応用的効果の中では、災害医療・救急医療におけるＩＣＴ支援サービスや、データ統計を自治体
が保健計画、医療計画の策定に活用、感染症の流行の傾向把握など疫学的な活用、介護予防、などの効果が期待できる。
また、本基盤を導入することにより、従来であれば個々のサービス提供主管課が各々の自助努力でやらなければならない、あるいは個別の主管課では実現困難なところを、福祉課や健診・保健センターなどで、保健事業の枠にとらわれないサービス提供が可能となる。このことは、導入していない他の自治体と比較して行政による住民サービスが充実しているという評価につながり、地域住
民の満足度の向上、ひいては地域の活性化につながるという長期的な効果が想定できる。

（２） 利用者が享受するメリット
３つの主な利用シーン（①住民向け健康情報サービス、②災害時医療・救急医療におけるＩＣＴ支援、③健康推進施策の策定、啓発活動）について、「生涯健康情報基盤」を利用する利用者毎に、どのようなメリットを享受できるかを以下に分類する。

① 住民−これまで自己管理が困難だった過去の健康情報が管理しやすくなる。
・保険者間の移動
・かかりつけ医療機関の変更
・毎回紙で発行される健診結果のファイリング
・自宅等で計測した測定データ（体重、血圧など）−自宅等で自分の健康情報の変遷を参照できることで、自己の健康管理に対する関心を持ちやすくなり、生活における行動変容へとつながる。
−どこの医療機関へ行っても、医学根拠に基づく過去の健康情報が引き継がれ、自分に最17
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

適な医療が受けられる。
−かかりつけ以外の医療機関に対して、セカンドオピニオンを求め易くなる。
−他の医療機関で受けた検査値を参照させることで、重複検査を回避することできる。
−薬剤師に常用薬やアレルギー情報を参照させることで、個人に最適な服薬指導が受けられる。
−個人の日々の健康状態や、介護事業者が登録するケアプランの内容、在宅療養支援診
療所に定期的な問診内容などを、離れて居住している家族が参照することにより、その個人の健康チェックをすることができる。

② 自治体（県、市町村）−エビデンスに基づいた保健・医療計画の策定ができる。
−地域住民の疾病状況を把握する。
−住民に正確な医療・健康情報を提供できる。
−予防措置の効果的な実施や、レセプトデータとの突合に活用することで、医療費の適正化にむけた政策的な取り組みにつなげる事ができる。
−災害時医療・救急医療において基盤内の個人情報を活かし、より安全な救急医療の提供を図る。
〈健診施設・保健指導施設（保健センター）などにおいて〉−過去の健康情報を経過的に参照できることで、より個人に即した効果的な保健指導サービス（エビデンスに基づいた保健指導計画の作成等）の実施−ネットワークを活用してリソースを有効活用した住民の健康づくりが進められる。
−医療機関等が「生涯健康情報基盤」にアクセスできる場合、個人による健康づくり支援に参画が可能となり、指導対象者数を広げることができる。
〈研究機関・国による公益分析〉−研究機関においては、疾病動向の把握に活用できる。
−国においては、疾病動向の把握により政策への反映ができる。

③ 医療機関（医療従事者）−患者の過去の健康情報を参照できることで、医学的根拠に基づいた情報から、患者に最適なきめ細かで質の高い医療を提供できる。（プライマリ・ケアの促進）−インフォームドコンセントの際、患者の過去の健康情報と照らし合わせて、分かり易く指導することができる。
−調剤薬局において常用薬データを参照することにより、患者に合わせた服薬指導ができる。
−救急医療の際に、患者の常用薬やアレルギー等の情報を得られることで、個人に最適な救急手段を選択することができる。
18
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

④ 介護サービス提供者−健康情報に基づく、より効果的な介護サービスが提供できる。
−個人に応じたケアプランの作成、ならびにケアプランを必要に応じて見直すことができ、要介護者の状態変化に即したケアプランに修正することができる。

２．５ 想定効果創出に向けた目標指標の設定
本節では、２．１節においての課題解決に向けた取り組みとして、システムによる効果を想定し、その実現の為に相対した目標設定が必要であることを記述する。

（１） 目標指標設定の方向性
指標設定の主体としては、地域の保健・医療・介護分野における行政サービスを担う課（保健福祉部・医療政策課・介護福祉課など）だけではなく、情報政策課や企画部・行政改革推進室などでも、本事業の取り組みに向けた指標設定が必要となる。
また、年度毎の指標設定も重要である。
したがって本項は、２．２課題の明確化と優先度設定の項と密接につながった設定指標を志向する。

（２） 指標設定
生涯健康情報基盤を活用して解決しようとする課題について 2.2 節で考察したが、その課題の解決に向けた指標設定が必要となる。そして、事業内容を改善していくために、定期的に評価を行うこと、これをサイクルとして固定化することが重要となる。そのため、立てた指標が事業そのものへのアプローチに影響を及ぼすので設定段階を重視すべきである。
実際の設定に際しては、例えば生活習慣病対策に向けた取り組みの定着と成果の管理について指標を立てる場合、特定健診業務の義務化などの制度に基づいた設定だけでなく、地域住民への行政サービスとしてより健康に暮らせる街づくりなどの施策の一環としての指標、という観点から検討し、具体的な項目としては下枠内のようなことが挙げられる。
利用者数、経済的効果、効率性、行政サービスの質的向上度合い、住民満足
度、将来へのデータ・ノウハウ蓄積度合い
地域によって設定するべき指標は異なるものであり、地域の実情を基に関連する施策とも整合を図りつつ検討されたい。

19
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

３ 基本要件定義と実現方式の策定

３．１ 情報活用全体像と基本要件ヒアリング結果（１） システム実現方法の全体像
本書で対象とする生涯健康情報基盤システムと、これまでの施設内情報システム、施設間連携
情報システム、また複数施設にまたがる情報システムとの関係を図 ３-１に示す。従来の紹介・逆紹介システム、遠隔画像・病理診断システム、また特定健診制度対応の各アプリケーションとは、目的、機能が異なることに注目して欲しい。
この部分の構築を提言している

生涯健康情報基盤
運営理念

遠隔画像・病理診断システム

生涯健康情報基盤システム

運営目標
運営体制

紹介・逆紹介システム

・・情報の維持・閲覧
匿名化
情報

健診

利用施設

地域連携パス・システム

医療自治体

運営管理規則

介護
情報の登録

運営資金

基本サービス（コア）

地域包括支援センター
システム

・
・

自己健康管理支援システム
比較的に高度なサービス（オプション）

委託※ 民間事業者による運営が望ましい

住民（個人）

医療機関

診療

病院情報システム

地域包括支援センター等

介護など

介護事業者システム

人間ドック、事業者
健診、生活機能評価
システム
医療保険者

健診・レセプト

特定健診・保健指導システム

図 ３-１ 生涯健康情報基盤システムと他システムとの関係
また、前章「２．３生涯健康情報基盤の定義と実現するサービス概要」で述べた基本サービス（コア）と比較的に高度な選択的サービス（オプション）との関係も「図 ３-１ 生涯健康情報基盤システ
ムと他システムとの関係」に示した。

① 生涯健康情報基盤システムの機能ブロック図
生涯健康情報基盤システムは、大きく以下のブロックで構成される。個人ごとの健康情報の保管および他ブロックから参照要求に対してデータ提供する「住民ごとの健康情報＆サービス」、住20
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

民の識別用キー情報の管理と住民の基本的属性情報、保険情報を管理する「住民基本情報サービス」、匿名化情報を管理する「健康施策・疫学統計サービス」、収集した生涯健康情報を適
切に振り分ける、また、参照要求に対して保管情報から適切に組み立てる「生涯健康情報の収集・参照サービス」、通信ネットワークに施設認証、個人認証などのセキュリティ機能を保証する「共通通信サービス」、そして利用者マスター、施設マスター、傷病名マスター、薬剤マスター、診
療科コード等のコード化テーブル、などを維持管理する「テーブル＆マスター部」からなる。
また、他地区（自治体）との連携には、より上位の地区連携サーバの管理下で情報交換を行う。
生涯健康情報基盤システム
住民基本情報サービス

テーブル& マスター
各種マス
ターと
コードテ
ーブル

住民属性

保険情報

情報

アクセス権限ルール

健康施策・疫学統計

住民ごとの健康情報＆サービス

健診・保健

診療

レセプト

指導情報

情報

情報

メッセージ

EHR
インデックス

構成情報

介護・福祉
情報

匿名化
情報

データベース
様式情報

生涯健康情報の収集・参照サービス

認証キー
情報

環境記述
Config

共通通信サービス
通信サービス

通信サービス

通信チャネル

匿名化情報

利用施設

保健指導
サービス

本人

医療機関
受診

本人

介護事業者
など

本人

自己健康管理

本人

災害医療
救急医療

災害時医師

保健行政
医療計画

自治体職員

(自宅から)

図 ３-２ 生涯健康情報基盤システムの機能ブロックのイメージ② 地域情報プラットフォームとの連携
業務間のインターフェイス標準仕様及び技術標準仕様やガイドラインで構成される「地域情報プラットフォーム」は、業務システム等を繋げる役目にあり、これによって自治体内システムの連
携、自治体間システムの連携、官民連携等によるワンストップサービスを実現すること、そして業務システム単位の容易な取り替えを可能とすることを目指すものである。平成１８年度に、地域情報 PF 標準仕様Ｖ1.0 を完成させ、平成１９年度に地域情報 PF 標準仕様Ｖ2.0 を作成中である。
地域情報プラットフォームの標準化対象は以下のとおりである。

21
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communicationア）業務ユニット毎に規定されたＷｅｂサービスの標準インターフェイス仕様により、業務ユ
ニットの差し替えを実現する基盤である。
イ）プラットフォーム通信機能により業務ユニット間をＸＭＬベースで取り決めたデータ交換を実現する基盤である。
ウ）ビジネスプロセス管理機能により、ビジネスプロセス定義で規定された複数のＷｅｂ
サービスの実行を実現する基盤である。
エ）プラットフォーム共通機能として、統合データベース、認証・許可、運用監視等の機能を提供する。

仕様
様
仕

業
業務
務モ
モデ
デル
ル標
標準
準

ｻｰ
ﾋﾞｽ協 調 技 術 標 準ｻｰﾋﾞｽ協

自
民間
自治
治体
体及
及び
び民
間が提
が 提供
供す
する
る地
地域
域情
情報
報サ
サー
ー
ビスの
必要
リユ ニットの
ビスの連
連携
携に
に必
要な
な業
業務
務ア
アプ
プリユ
ニ ットのイ
イ
ンタ
フェー
ス仕
ン タフ
ェース
仕様
様

サ
サー
ービス連
ビス連携
携を
を支
支え
える基
る基盤
盤ア
アプリの
プ リの諸
諸要
要件
件・・
プ
決め
プロ
ロトコ
トコル等
ル 等を取
を 取りり決
めた
た仕
仕様
様

自
ニ ット
自治
治体
体業
業務
務ア
アプ
プリケ
リケー
ーシ
ションユ
ョン ユニ
ット
標
標準
準仕
仕様
様

ア
アー
ーキ
キテクチ
テク チャ標
ャ標準
準仕
仕様
様
プ
ットフ
ォー ム
プラ
ラット
フォー
ム通
通信
信標
標準
準仕
仕様
様
相
相互
互接
接続
続仕
仕様
様

ガイ
イド
ドラ
ライ
イン
ン︵
︵
指針
針︶
︶
ガ
指

仕
導入
仕様
様に準
に 準拠
拠し
した
たサ
サー
ービス基
ビス基盤
盤、
、お
および業
よ び業務
務ア
アプリケ
プ リケー
ーシ
ションを
ョンを導
入する
す る調
調達
達者
者向
向け
けに
に必
必要
要
な
、 とりま
め たも
の
な事
事項
項を
を、
とり まととめ
た もの
地
トフォー
ガイ
イン
地域
域情
情報
報プ
プラッ
ラットフ
ォーム
ムガ
イドラ
ド ライ
ン

地
トフォー
地域
域情
情報
報プ
プラッ
ラットフ
ォーム
ムの
の基
基本
本説
説明
明書
書
地
トフォー
地域
域情
情報
報プ
プラッ
ラットフ
ォーム
ム標
標準
準仕
仕様
様運
運用
用規
規則
則

図 ３-３ 地域情報 PF 標準仕様の成果物体系
従って、生涯健康情報基盤システムとの連携については、「高齢者福祉」、「乳幼児医療」、「母子医療」および「健康管理」等の密接な関係にある業務ユニットに関する標準インターフェイスの完成を待つところであるが、現段階での基本的な連携方針を以下に示す。
生涯健康情報基盤システムは、「住民基本台帳」、「国民健康保険」、「障害者福祉」、「高齢者福祉」、「介護保険」、「乳幼児医療」、「母子医療」、「健康管理」等に関係する新たな業務ユニットと考えられる。そして、個人のセンシティブな健康情報を扱うため、既存の業務ユニットとは、独立した運用管理、セキュリティ区画として扱うことが望まれる。また、住民の各種情報が一元管理されないよ
うに双方向の情報パスには一定の制限を設けることが必要と考えられる。
生涯健康情報基盤システムのアーキテクチャ及び技術標準を、地域情報プラットフォームのそれと同じ方針としておくことが、将来の相互接続性を高めると考えている。従って、図 ３-４ 地域情報
PF の技術候補マップの技術標準をベースとすることが望ましい。
22
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

【サイト間】
ＩＣＴ
サービス

サービス連携型アプリケーション、運用管理アプリケーション、共通サービス
統合ﾚｼﾞｽﾄﾘ、
プライバシ
合意等適用技術
情報公開
and(オプション))（UDDI 2.0 or(プライバシ情報
ebXML R&R）
公開技術 and
ビジネス文書定義、インタフェース定義、 P3P)(オプション) （オプション）
ビジネスプロセスの定義（ UML、BPMN、WS-BPEL2.0
Webサービス情報
XML Schema1.0 、WSDL1.1 ）の登録と検索ビジネス文書セキュリティ（オプション）（オプション） （UDDI2.0 ）( XML Signature 1.0 and(JPKI or その他証明書))(LGPKI and (XML Signature1.0 or
PKCS#7））
サービス＆BP定義手法（デザインパターン定義・生成）（オプション）

地域情報プラットフォーム

モデル定義言語（UML、BPMN）

モニタリング技術(オプション)

サービス連携・統合機能（BPM機能）（WS-BPEL 2.0）

Webサービス
運用管理（オプション）

サービス認証、サービス認可（オプション）
プライバシー保護型認証連携技術（オプション）

開発環境

サービス
監査証跡
(オプション)（サービス監査証
跡取得技術)

権限管理基盤技術 and XACML2.0 （オプション）

添付付きメッセージング （オプション）（本文に埋め込み型 and MIMEで添付型(SwA) and BPMと連携した本文内に埋め込み型）
高信頼メッセージング（オプション） （ WS-Reliability 1.1 or WS-ReliableMessaging 1.1 ）基本メッセージ （ SOAP 1.1 and WS-I Basic Profile 1.0 ）ネットワーク ／通信

転送プロトコル （ HTTP 1.1 ）通信路セキュリティ （ SSL3.0 and TLS1.0)）
インターネットプロトコル （ IPv4 ）OS （ Windows or UNIX or Linux）

地域情報プラットフォーム標準化範囲

サービス開発環境

図 ３-４ 地域情報 PF の技術候補マップ（２） 共同研究ヒアリング結果のまとめ
平成１９年度に実施した先進自治体との共同研究において、生涯健康情報基盤を実現する際の基本的要件をヒアリング調査したので整理して報告する。①機能要件、②セキュリティ要件、③標準化要件、④推進方法、そして⑤運営主体と事業継続性、について述べる。

① 機能要件ア）個人の健康情報（保健、医療、介護、福祉に係わる情報）の集約を基本に、地域の住
民の健康づくりを支援するシステムである。従って、自治体と保健、医療、介護、福祉の各サービス提供機関との連携のもと、住民の立場での一貫したサービスを提供できることが重要である。従って、施設および医療保険者にとらわれない広域情報、かつ23
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

長期の情報がそろっていることが望ましい。
イ）特に、保健分野の健診、保健指導情報については、生活習慣病の予防という観点から住民が自らの健康情報にアクセスし健康管理に活用する手段をサポートすることが望ましい。
ウ）医療情報と健診、保健指導情報がシームレスに見られることで、診療の精度および、
保健指導の効果は向上すると考えられる。年１回の健診結果だけではなく、医療機関
での検査結果も合わせて一連性あるかたちで保存参照できることが必要となる。
エ）疫学統計的な活用および保健医療福祉施策への反映を目的とした「匿名化健康情報」の収集および利用のしかたについても、国の動向を注視しつつ検討する必要がある。
オ）医療・保健・介護従事者（有資格者）のみならず、地域住民自ら利用可能な健診情報
データベースであること。
カ）特定健診・特定保健指導の他に、人間ドッグ、がん検診、等も含めること、また乳幼児健診、学校健診から特定健診までの一連のデータがそろっていることが望ましい。
キ）メタボリック対策だけでなく、地域特性に応じて脳卒中、高血圧など対象を広げられること。
ク）経年的、時系列表示を示し、同年代の全体での個人の位置づけを提示し、個人が自分の立場、位置を理解し、生活習慣病予防のための行動変容トリガーとなることが望ましい。
ケ）特定健診、特定保健指導と行動変容等の情報を蓄積することにより、有効性の確認と地区別効果分析が可能となること。
コ）診療情報としては、保健、医療、福祉関連施設間で利用可能なデータベースとするべきである。医療機関等を越えて利用性の高い情報から集約対象とすべきである。現病名、既往歴、家族歴、禁忌・アレルギー情報、服薬情報、検査結果、画像検査結果、予防接種歴、等サ）診療情報には既に電子化されているレセプト情報を含めること。

② セキュリティ要件
ア）健康情報は個人情報であり、集約収集および閲覧については、原則本人の同意が必要である。個人からの委任で健康情報を預かる考え方が適切とのこと。また、主旨、情報の範囲、利用目的等について十分に住民の理解を得られた状態にすることが大切である。
イ）集約収集および閲覧に係わる本人の意思確認、参照者指定の具体的運用は、各地域に委ねられる。今後の普及のためには国レベルの一定のガイドラン等があることが望ましい。（地域における規定つくり、閲覧期限の設定など）。
ウ）厚生労働省が示している「医療・介護関係事業者における個人情報の適切な取扱いのためのガイドライン」、「健康保険組合等における個人情報の適切な取扱いのため
24
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

のガイドライン」、「医療情報システムの安全管理に関するガイドライン第二版」､等に準拠することは言うまでもなく、地域でセキュリティに関する方針を検討し、運用規定として明示すること。

③ 標準化要件ア）健診データの様式を統一し、情報を指導や診療の目的に沿って分類し、団体に拠らず
統一感のある表示様式にする必要がある。
イ）現在示されている特定健診データの仕様（ＸＭＬ形式）だけでなく、特定健診項目以外の健診項目についてもデータ出力時の標準的な仕様を決めるべきである。
ウ）検査結果値の標準化（精度管理）も重要である(特定健診項目以外)。
エ）共有する基本的な診療情報は標準化が必要である。

④ 推進にあたり留意すべき事項
ア）効果分析等を行い、ＩＣＴ導入の経済的な有効性を明確にする必要がある。
イ）健康情報の基盤整備について国レベルの方針が明確になると、自治体（都道府県、
市町村）としては対応がしやすい。
ウ）都道府県・市町村レベルでの条例等（自治体における情報管理のセキュリティ担保、
健康情報の委任、参照者指定方法、住民負担）の整備が必要である。自治体の対応について一定レベルの国の指針が望まれる。
エ）収集した情報の利用目的を明確化し、情報の取扱い者、情報の対象範囲および取扱い範囲等を整理する必要がある。

⑤ 運営主体と事業継続性
ア）運営主体については、地域特性に委ねるべきで一定の考え方は存在しないと考えられる。従って、ヒアリング等で収集した意見を並記することにとどめる。
○組織をまたいで情報収集等をしなければならない新規分野においては、行政が責任を持って主導していくべきである。
○行政、地区医師会、医療保険者など関係機関の協力体制での運営が望まれる。

イ）利用促進の立場からは負担なしが望ましい。運営コスト捻出から一部利用料を徴収することを考慮する余地はある。その場合でも、コストと行政負担などの折り合うところで、できるだけ低額が望ましい。
ウ）費用負担、利用料の徴収については、モデル事業等での検証が必要である。

３．２ 生涯健康情報の対象範囲の策定（１） 住民の健康をとりまくデータに関して
住民の健康に関する情報には、健康診断（診査）での健診データ、医療機関での診察データ、その他の日常生活における自己健康管理データ等が存在する。
個人に関する健康データは多数存在し、その中で、生涯健康情報に関係すると考えられるデータ
25
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

を以下に一覧として記載する。

① 健診データに関して
表 ３-１ 健診データの一覧
健診の種類

データの内容基本健康診断（診査）

身体計測・血圧測定・尿検査・ 血液検査・心電図・胸部Ｘ線検査・眼科系検査・聴力検査等の検査結果

特定健診

身体計測・血圧測定・血液検査 等の検査結果

がん検診

肺がん・胃がん・大腸がん・乳がん・子宮がん 等の検査結果

人間ドック

身体計測・血圧測定・尿検査・ 血液検査・心電図・胸部Ｘ線検査・
胃Ｘ線検査・眼科系検査・聴力検査 等の検査結果
身体計測・血圧測定・尿検査・ 血液検査・心電図・胸部Ｘ線検査・眼科系検査・聴力検査等の検査結果

労安衛法の健康診断
生活機能評価身体計測・歩行機能など

妊婦健診

血液検査・超音波検査の検査結果

乳幼児健診

身体計測・尿検査・歯科検診 等の検査結果

学校健診

身体測定・心電図・胸部Ｘ線検査 等の検査結果② 医療機関でのデータに関して
表 ３-２ 医療機関データの一覧
診察の種類

データの内容診察データ

投薬・処置・病歴・指導・検査結果 等

感染症歴

麻疹・水痘・百日咳・おたふくかぜ・風疹 等

画像データ

ＭＲＩ・ＣＴ 等

各種検査結果血液検査・尿検査 等の検査結果

予防接種歴

予防接種の履歴

レセプトデータ

診療報酬のデータ。投薬や処置、病名の内容が含まれている。

調剤データ
アレルギーデータ

調剤薬局での調剤情報
アトピー性皮膚炎・アレルギー性鼻炎（花粉症）・気管支喘息・食物アレルギー ・薬物アレルギー 等

禁忌

禁忌情報

③ 日常生活における自己健康管理のデータに関して
表 ３-３ 日常生活データの一覧
健康管理データの種類

データの内容身体の測定データ

身長・体重・腹囲 等

血圧

自宅で測定する日々の血圧

運動履歴

日々の運動履歴26
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

（２） 対象範囲を策定するにあたって① 住民に必要とされる生涯健康情報
個人の健康を管理する上において「生涯を通した健康情報」は必要不可欠なデータである。生涯を通した健康情報データが存在する事により、健康意識の改善や、それに付随する行動変容が期待される。時系列で比較可能な健康管理データと運動データが存在する事により、日々の運動量と比較した体重・腹囲等の変化がわかり、その効果として定期的に実施される健康診断（診査）の結果に変化が見られることは本人の励みとなり、健康への行動変容に繋がると考えられる。それらを実現させるためには、日常生活における自己の健康管理データや健康診断（診査）のデータ、医療機関での検査結果や投薬・既往歴のデータをデータベース化する必要がある。
また、これらのデータベース化は災害時の救急医療においても有用なデータとなる。

② 現時点でのデータ提供の実現性
各種健診データにおいて、現地点では特定健診以外の健診データは電子化されていない場合が多く、電子化されていたとしても検査機関による検査基準値に違いがある。これらの理由により、データ提供の実現性において、現時点で対象となりえるのは完全電子化され、基準値の標準化がなされている特定健診のデータのみであると考えられる。但し、住民の生涯健康情報を構成するデータとしては、特定健診以外の健診データも必要であるので、これらのデータが電子化され、基準値の標準化が進むことに期待する。
医療機関における診療データに関しては、電子カルテからの収集が考えられるが、現在の電子カルテ導入率やデータの標準化がなされていない事から考えると、電子カルテからのデータ収集は容易でないと考えられる。代替案としては、平成２２年４月から「原則オンライン請求」となる
医療機関の診療報酬請求のデータ（レセプトオンラインデータ）が考えられる。この診療報酬のデータには投薬歴や病歴等の情報が含まれ、診療データとしての利用が可能であると考えられる。また、医療機関での検査データや画像診断データも生涯健康情報には有用なデータではあるが、その収集の仕組みや運用の手順の構築を考えた場合、医療機関における医療情報との連携は、当面は最小限で押さえる事が現実的であると考えられる。よって生涯健康情報基盤における医療情報データの範囲は診療報酬のデータ（レセプトオンラインデータ）から収集可能な投薬データと病歴データが現地点での現実的なデータであると考えられる。
日常生活における自己健康管理データに関しては、日々の運動履歴やバイタルデータのデー
タベース化が考えられる。これらのデータを健診結果と比較する事により、運動効果の測定が可能になり、健康意識の高揚が期待できる。ただし、地域特性を考慮する必要があるが、このサービスは民間事業者が手がけていることも考慮して、生涯健康情報としては当面、見合わせるのが妥当と考える。

（３） 「生涯健康情報基盤」の対象と考えられる情報
前記の「住民に必要とされる生涯健康情報」と「現地点でのデータ提供の実現性」を考えた場合、
27
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

地方自治体においては、以下が対象可能なデータとして現実的なラインであると考えられる。

① 健診データに関して電子化されている特定健診、特定保健指導のデータを対象とする。

② 医療機関でのデータに関して
レセプトオンラインデータを対象とする。

③ 日常生活における自己健康管理のデータに関して
現時点では対象可能なデータはない。
以下に対象可能となるデータの詳細を記する。
表 ３-４ 生涯健康情報基盤の対象データの一覧
データの発生元

データ項目

特定健診

身体計測

身長
体重
ＢＭＩ
内臓脂肪面積腹囲(実測）
腹囲(自己判定）
腹囲(自己申告)

診察

既往歴（具体的な既往歴）
自覚症状
（所見）
他覚症状
（所見）

血圧等

収縮期血圧（その他）
収縮期血圧（２回目）
収縮期血圧（１回目）
拡張期血圧（その他）
拡張期血圧（２回目）
拡張期血圧（１回目）

採血時間（食後）生化学検査

中性脂肪（トリグリセリド）
ＨＤＬコレステロール
ＬＤＬコレステロール
ＧＯＴ（ＡＳＴ）
ＧＰＴ（ＡＬＴ）28
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

データの発生元

データ項目
γ‑ＧＴ(γ‑ＧＴＰ)
血糖検査

空腹時血糖
随時血糖
ＨｂＡ１ｃ

尿検査

尿糖
尿蛋白

血液像検査

ヘマトクリット値
血色素量［ヘモグロビン値］
赤血球数
貧血検査（実施理由）

がん検診・生体検査等

心電図（所見の有無）
心電図（所見）心電図（実施理由）
眼底検査（キースワグナー分類）
眼底検査（シェイエ分類：Ｈ）
眼底検査（シェイエ分類：Ｓ）
眼底検査（ＳＣＯＴＴ分類)
眼底検査（その他の所見）
眼底検査（実施理由）

医師の判定

メタボリックシンドローム判定
保健指導レベル医師の診断（判定）
健康診断を実施した医師の氏名

質問票

服薬１（血圧）（薬剤）（服薬理由）
服薬２（血糖）（薬剤）（服薬理由）
服薬３（脂質）（薬剤）（服薬理由）
既往歴１（脳血管）既往歴２（心血管）

29
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

データの発生元

データ項目
既往歴３（腎不全・人工透析）
貧血
喫煙
２０歳からの体重変化
３０分以上の運動習慣
歩行又は身体活動
歩行速度
１年間の体重変化
食べ方 1（早食い等）
食べ方２（就寝前）
食べ方３（夜食/間食）
食習慣
飲酒
飲酒量
睡眠
生活習慣の改善
保健指導の希望

レセプト

医療機関情報医療機関名称

オンラインデータ

レコード

請求年月

傷病名レコード

傷病名コード
診療開始日
転帰区分
修飾語コード
傷病名称
主傷病

医薬品レコード

診療識別
医薬品コード
使用量回数【出典：健診データの電子的管理の整備に関するホームページ http://tokuteikenshin.jp/】【出典：レセプト電算処理システム 電子レセプトの作成手引き http://www.ssk.or.jp/】
但し、上記以外のデータにおいても、今後、標準化、電子化された場合には、生涯健康情報基盤の対象として、順次追加が可能であると考えられる。（例えば人間ドッグ等のデータ、医療機関での検査結果、調剤薬局での調剤情報、など）
30
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

３．３ 生涯健康情報を扱うシステム間インターフェイスの標準様式（１） 健康情報に係わる標準化の状況
健康情報のデータ交換規約について、これまで様々な取り組みがなされており、生涯健康情報基盤の構築に向けた環境が整いつつあるので、その状況を以下に示す。システム間のデータ交換
規約については、通信プロトコル、データ様式、そして用語・コードが定められている。ここでは、技術進歩の影響を受けやすい通信プロトコルは、検討対象からはずして、データ交換規約におけるデータ様式と用語・コードについて注目する。

① 特定健診・特定保健指導の交換データ様式
厚生労働省の「標準的な健診・保健指導プログラム【２００７年３月２６日確定版（案）】」、および「特定健康診査・特定保健指導の円滑な実施に向けた手引き」に基づき、以下のデータ様式が定められている。
・特定健診・特定保健指導の報告ファイル仕様
・健診情報・特定保健指導情報ファイル仕様
・用語･コードは、ＭＥＤＩＳ臨床検査マスターでも使用している JLAC10 コードを採用
詳細は、以下のホームページを参照されたい。
http://tokuteikenshin.jp/② レセプト電算処理システムの交換データ様式
診療報酬請求に係わる医療機関からの請求様式は、光ディスク又はオンラインによる請求の規格及び方式として定められている。ここでは、これを様式Ａ（医療機関用）と呼ぶ。例えば、医科用、DPC 用、調剤用については、・光ディスク等又はオンラインによる請求に係る記録条件仕様（医科用）（別添 1-1）
・光ディスク等又はオンラインによる請求に係る記録条件仕様（ＤＰＣ用）（別添 1-2）
・光ディスク等又はオンラインによる請求に係る記録条件仕様（調剤用）（別添 1-3）
・用語・コードは電子レセプト用基本マスターを使用として登録されており、ダウンロード可能である。詳細は、以下の URL を参照されたい。
http://www1.iryohoken.ne.jp/rece̲info.html
このホームページには、医療機関向けの様式のほかに、保険者向け記録条件仕様も登録されている。審査支払機関から各保険者に送付される様式が規定されている。この保険者向け記録
条件仕様を、ここでは様式Ｂ（保険者用）と呼ぶ。様式Ｂのなかで、レセプト情報は、様式Ａに則ったフォーマット仕様をそのまま使用している。

③ 医療情報の交換データ様式
医療情報に係わる標準データ様式として、日本ＨＬ7 協会の「患者診療情報提供書規格」と、保31
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

健医療福祉情報システム工業会の「医療情報システムにおける相互運用性の実証事業 成果」との２例について述べる。
・http://www.hl7.jp/intro/index.html
・http://www.jahis.jp/sougounyou/sougounyou̲top.html
患者に提供する診療情報を電子的に記述する様式として、上記のＨＬ７ ＣＤＡ Ｒｅｌｅａｓｅ2 に基づいた診療情報提供書と共通の様式としている。
・用語・コードはＭＥＤＩＳ標準本マスターを使用（２） システム間インターフェイスの標準様式の検討
生涯健康情報基盤システム内部の記録様式そのものは、既存の蓄積データの存在とか、技術進
歩への対応、システムの自由な競争を考慮すると、標準化して制約することのデメリットが大きい。
従って、ここでは各システム間の情報交換の様式を標準化すること、および生涯健康情報基盤システム内部の記録様式については、事例を挙げることに止めることを基本方針としたい。

① 生涯健康情報基盤のシステム間インターフェイスの標準化（予定）
ここでのインターフェイスは、例えば、データセンタのサーバと利用施設のパソコン間の検索ク
エリと応答メッセージの様式などである。
・健診情報および保健指導情報は、厚生労働省研究班で設定しているＨＬ７ ＣＤＡ Ｒｅｌｅａｓｅ2の様式が情報交換用のものでありそのまま使用することが望ましい。そして、例えばアタッチメ
ント付きＳＯＡＰメッセージ形式でＣＤＡを交換する方法などを検討する。
・レセプト情報などの医療情報は、ＸＭＬ形式が望ましく、健診情報に合わせてＨＬ７ ＣＤＡ Ｒｅｌ
ｅａｓｅ2 の形式とするか、または別の様式とするかを検討する。

② 生涯健康情報基盤システムの記録様式の事例（予定）平成 20 年度の共同研究あるいは実証事業において、生涯健康情報基盤システムの内部記録様式を事例としてあげる予定である。
・健診情報は厚生労働省研究班で設定しているＨＬ７ ＣＤＡ Ｒｅｌｅａｓｅ2 の様式をそのまま使用する、または、ＨＬ７ ＣＤＡ Ｒｅｌｅａｓｅ2 の様式に変換しやすい形式で記録することが考えられる。
・レセプト情報などの医療情報は、ＸＭＬ形式が望ましく、健診情報に合わせてＨＬ７ ＣＤＡ Ｒｅｌｅ
ａｓｅ2 の形式とするか、または別の様式とするかを検討する。日本ＨＬ７協会の「患者診療情報
提供書規格」に準拠する様式、またはこれに変換し易い様式などを検討する。
生涯健康情報システム内部の記録様式は、あくまで事例であり、これでないといけないというものはない。
以上の①、②について平成２０年度報告の基本提案書（第２版・詳細版）作成にあわせて検討する。
32
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

（３） 健康情報における推奨の用語・コード① 電子レセプト用基本マスター
基本マスターとは、電子レセプト請求のための統一コードに、価格や点数、算定条件等の各種情報を付加した電子的マスターファイルである。
表 ３-５ 基本マスターの種類
マスターの種類

概要（主な記録項目）

診療行為マスター

医科診療行為名称等を記録 （診療行為名称・コード、点数、点数計算情報）

傷病名マスター

傷病名に関する情報を記録、電子カルテ用標準病名マスター収載病名が完全に一致（約１９、５００語） （傷病名・コード、ＩＣＤ分類コード）

修飾語マスター

傷病名に係わる部位等を表す修飾語を記録 （修飾語・コード）

医薬品マスター

薬価基準に基づく医薬品名称等を記録 （医薬品名・コード、薬価、単位）

特定器材マスター

特定保険材料名称等を記録 （特定器材名称・コード、属性、規格、価格）

コメントマスター

レセプト摘要欄記載情報を記録 （コメント文・コード）

基本マスターは、厚生労働省と審査支払機関が管理しており、診療報酬や薬価等の改定時に、改定後の電子ファイルの提供がある。基本マスターは、次のホームページから自由にダウンロードできる。 ＵＲＬ = http://www.iryohoken.ne.jp② ＭＥＤＩＳ標準マスター
医療施設間での電子的情報交換等の目的に標準的な用語・コードが必要となり、厚生労働省からの委託で（財）医療情報システム開発センター（ＭＥＤＩＳ−ＤＣ）が整備したのがＭＥＤＩＳ標準
マスターである。

ア）病名マスター（ＩＣＤ１０対応電子カルテ用標準病名マスター）イ）医薬品マスター（ＨＯＴ番号）ウ）臨床検査マスター（生理機能検査を含む）
エ）手術・処置マスターオ）医療機器データーベースカ）看護実践用語標準マスター ＜看護行為編＞ ＜看護観察編＞
キ）症状所見マスター＜身体所見編＞
ク）歯科分野マスター ＜病名＞ ＜手術・処置＞
ケ）画像検査マスター
詳しくは、以下のＭＥＤＩＳホームページを参照のこと。このホームページから標準マスターをダ
ウンロードすることも可能である。

http://www.medis.or.jp/4̲hyojyun/medis‑master/index.html を参照。

33
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

３．４ 方式策定（１） 情報の保管／活用形態
生涯健康情報を住民情報サービスの一環として地域で保管／活用する形態を検討する際、当面は大きく２つの要素を考慮する必要がある。一つは、地理的広がり、規模、参画組織により構成モデルが異なること。もう一つは、サーバのデータ保管形態として集中方式と分散方式の２形態があること。将来的には、全国的に種々の形態が混在しても標準インターフェイスは、共通となるよう当初から計画しておかないと普及時に混乱を招くことになる。

① 地理的広がり、規模、参画組織による構成モデル
都道府県および市町村の規模および方針に応じて、健康情報基盤の構築のアプローチが異なると考えられる。ここでは、代表例として、ア）都道府県と市町村の連合モデル、イ）市町村連合
モデルの２つについて検討案を示す。市町村の他に地域の参画機関として、医療機関、薬局、地域包括支援センター、健康保険組合、などがあるが構成モデルの検討のため構成を省略抽象化
している。

ア）都道府県と市町村の連合モデル（A パターンと呼ぶ）
都道府県が推進役となり、大規模でない 30 万人〜40 万人以下の市町村の生涯健康情
報を都道府県単位で集約的に管理運営する形態が考えられる。都道府県単位で集約的に管理運営する範囲は、住民基本属性情報、保険情報、および生涯健康情報の在り処情報（EHR インデックス）、そして集中方式の場合は生涯健康情報そのものの収集維持、そして
閲覧サービスとなる。
他地区連携サーバを都道府県単位のデータ管理運営センター内に設置している。
他の都道府県

都道府県単位のデータ管理運営セン ター
他地区
連携

住民ごとの 健康情報＆サ ービス

住民 基本情報サービス

健診・指導

住民属性

レセプト
介 護福祉

・保険情報

診療

匿 名化

情報

情報

大規模市町村

他県・大 規模市町村
生 涯健康情報基盤

EHR
インデックス
共通通信サービス

通信サー ビス

共通通信サービス

健診・
保健指導

レセプト

市町村 Ａ

通信
サービス

通信チャネ ル

介護福祉

共通通信サービス

・・・

健診 ・
保健指導

レセプト

介護福祉

市町村 Ｂ

図 ３-５ 都道府県と市町村の連合モデル（パターンＡ）
34
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communicationイ）市町村連合モデル（Ｂパターンと呼ぶ）
２０万人〜３０万人くらいの地域（概ね二次医療圏に相当）で市町村が連合して、データ管理運営センターを設置するモデルが考えられる。図 ３-６は２つの市町村連合が他地区連携サーバを介してお互いに情報交換するモデルを示す。
他地区連携サーバの運用は、市町村連合間での話し合いでどちらかのデータ管理運営
センター内に設置するのが望ましい。
市町村連合のデータ管理運営センター ２

市町村連合のデータ管理運営センター １
住民基本情報サービス

住民ごとの健康情報＆サービス
健診・指導
レセプト
介護福祉

住民属性
・保険情報

診療
情報

診療

匿名化
情報

情報

共通通信サービス

共通通信サービス

通信サービス

通信チャネル

介護福祉

健診・指導
レセプト
介護福祉

住民属性
・保険情報

EHR
インデックス

共通通信サービス

レセプト

匿名化
情報

住民ごとの健康情報＆サービス

住民基本情報サービス

EHR
インデックス

通信サービス

健診・
保健指導

他地区
連携

共通通信サービス

・ ・・

健診・
保健指導

市町村 Ａ

レセプト

介護福祉

市町村 Ｂ

通信チャネル

共通通信サービス

健診・
保健指導

レセプト

介護福祉

共通通信サービス

・ ・・

市町村 Ｃ

健診・
保健指導

レセプト

介護福祉

市町村 Ｄ

図 ３-６ 市町村連合モデル（パターンＢ）
パターンＡ、パターンＢのシステム構造上の大きな違いはないことが判る。このため、パターンＡ、パターンＢが混在してもネットワーク上のインターフェイスが標準化できることがわかる。

② データ保管形態による構成モデル
データ管理運用センターのサーバに、健康情報を集中保管するか、それとも情報ソース保有者がそのまま地理的に分散した状態で保管するか、大きく２つの選択がある。

ア）データ集中保管モデル
一箇所のサーバ上にすべての健康情報を集約して保管する。情報ソースで情報が発生する都度、基本的にはリアルタイムで、サーバにデータ送信し、サーバ側で保管する。利用者は、サーバにアクセスして、必要な情報を取得する。
センターサーバに情報を集約するため、情報の標準化強度が強く、データの信頼性を高めることが可能となる。一方、情報を２カ所で重複して保管するため、ＩＴ資源の無駄が発生する。

イ）データ分散保管モデル
健康情報は情報ソース保有者が、従来どおり保管し、検索用の在り処情報（ＥＨＲインデックス）のみをセンターサーバ保管する。利用者は、センターサーバのＥＨＲインデックスを検索し、応答で得られるＥＨＲインデックス情報をもとに、健康情報そのものを、情報ソース保35
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

有者から取得する。
情報ソース保有者の既存システムの改修が少なく、普及性が高い。一方、システムの構造が複雑であり、多数の情報ソース保有者への横断的なアクセスが一時期に集中的に発生する分析・統計などの処理時間が長くなる傾向がある。
両者のメリット、デメリットを考慮して選択が必要である。他地区連携を考慮すると、いずれにしてもＥＨＲインデックスの導入が必要である。そのため、データ集中保管モデルの場合
でも、自サーバに保存している健康情報のアクセスの際に、ＥＨＲインデックスを使用することを推奨する。
ＥＨＲインデ ックス

セ ンター

住 民 ごとの 健 康 情 報 ＆ サ ー ビス

住 民 基 本 情 報
サ ー ビス

健 診 ・指 導住 民属 性レセプト

・保 険 情 報

介護 福祉

診療
情報

ＥＨＲ
インデ ックス
共 通 通 信サ ービス

通 信 サ ー ビス

通信チ ャネ ル① イ ン デ ックス 登 録③ 応 答 （インデックス）

共 通 通 信サ ービス

④データ
取 得
健 診・
保 健指導

レセ プト

介 護福祉

情 報 ソ ー ス 保 有 者 （市 町 村 ）

②検 索
個人 健康
管 理

住民

利 用者

図 ３-７ データ分散保管モデル（２） 住民識別キー
地域内および他地区連携において、住民のユニークな識別キーは重要である。社会保障に係わるユニークな識別キー（ＩＤ）が活用できる場合は、名寄せ処理が省略できるため、システムが簡素な構造となる。ユニークな識別キー（ＩＤ）が活用できない場合は、名寄せ処理による地域でのユ
ニーク住民ＩＤの管理が必要となる。

① 社会保障カード（仮称）の活用
現在、検討中の段階であるが、社会保障に係わるユニークな識別キー（ＩＤ）が付与され、そのＩ
Ｄが生涯健康情報基盤で活用できる場合には、そのユニークＩＤで全国に配置される推定２００程
度の他地区連携サーバに、該当住民の健康情報の有無と在り処を短時間に確認可能となる。
各参加施設においては、社会保障カードのユニーク識別キーと各施設の既存ローカルＩＤとのリンクが必要となるが、個人の健康情報の正確な管理が期待できる。

36
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

② 地域でのユニーク住民 ID の使用
社会保障に係わるユニークな識別キーの活用ができない場合は、地位でユニークな住民ＩＤを導入し、他地区連携の場合は地区間で、地域ユニーク識別キーどうしのリンク手続きが必要となる。
名寄せ処理による地域ユニーク識別キーのリンクは、精度および処理時間上で課題が多く、他地区連携に運用上の制限が生じる可能性が高い。そのため、将来的には、社会保障に係わるユニークな識別キーの整備を望む。

（３） 匿名化情報の集配信
健康施策の策定における現状把握と、施策の効果測定、また、健康増進施策のポピュレーショ
ン・アプローチにおける根拠に基づいた説得力ある啓発材料の作成、などのために、地域における保健医療福祉サービスの状況を定量的・経時的に把握することが必要となる。そのための匿名化
健康情報の収集は、データ統計の重点目標を設定して、必要なデータ項目を、個人識別情報を除いてマスデータとして一括収集することが効率的である。個人情報保護に配慮しつつ健康情報を時系列で蓄積するため、健康情報を匿名化すること、そして、健康情報を疫学的活用により健康施策
がより根拠ある活動となり健康増進につながるという点について住民の理解を得る日頃からの説明が必要である。
地域別の健康特性、疾病別の特性、健康増進施策の実行前後の比較、医療計画のアウトカム
評価など重点目標を絞った統計的、疫学的な分析を行うこと、そして、多種多様のデータをデータマイニングして、新たな特性を見いだすなど方法の検討が必要である。

３．５ セキュリティ概要設計（１） セキュリティ関連の基準、仕様書の概括
健康情報基盤の構築に際して、ネットワークも含めて、信頼性やセキュリティの高いシステムを構築するための基準やガイドラインが多く存在する。以下に代表的なものを示す。

ア）地域公共ネットワークに係わる標準仕様
http://www.soumu.go.jp/joho̲tsusin/manual/ck̲network.html

イ）情報システム安全対策基準
http://www.meti.go.jp/policy/netsecurity/downloadfiles/esecu03j.pdfウ）情報通信ネットワーク安全・信頼性基準
http://www.soumu.go.jp/joho̲tsusin/whatsnew/kokuji/network̲0203.html#r-1

エ）地方公共団体における情報セキュリティ対策に関する調査研究報告書
http://www.soumu.go.jp/singi/security.pdf
さらに、健康情報に関連して、上記のものに追加の位置づけで以下の基準、ガイドラインがある。

37
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communicationオ）医療介護関係事業者における個人情報の適切な取扱いのためのガイドライン
http://www.mhlw.go.jp/houdou/2004/12/h1227-6.html

カ）健康保険組合等における個人情報の適切な取扱いのためのガイドライン
http://www.mhlw.go.jp/topics/bukyoku/seisaku/kojin/index.htmlキ）医療情報システムの安全管理に関するガイドライン第２版
http://www.mhlw.go.jp/shingi/2007/03/dl/s0301-12a.pdf

ク）「レセプトのオンライン請求に係るセキュリティに関するガイドライン（平成１８年４月厚生労働省）（２） 生涯健康情報基盤構築における個人情報保護法対応の基本的な考え方① 健康情報の保管は本人からの委託、情報の参照は本人の同意が原則
個人の健康情報に関しては、本人の意思に反して、個人データが他人に見られる、また漏えい、
滅失又はき損等をした場合に本人が被る権利利益の侵害の大きさを考慮して、個人の人格尊重の理念の下に慎重に取り扱うことが必須である。
従って、個人の健康情報の収集・保管においては、本人からの委託があること、そして個人情報を参照できる対象者に関して本人の同意が原則である。
その他の運用についても、上記の基準、ガイドラインを遵守すること。

② 委託保管の意思確認と参照先の指定方法
健康データの収集・保管についての本人からの委託の意思確認の方法について、具体的に検討する。例えば、電子媒体に格納された情報を本人が持参して保管要請がある場合は、本人の意思確認が明確である。しかし、通常は、健診結果、および診療結果としてのレセプト情報については、本人がデータを携行しているわけではなく、電子情報として画面で確認するか、印刷物として内容を確認するしか本人は手にすることができないのが実情である。
従って、個人情報の委託にあたり、本人の委託意思の確認と参照が可能となる者の指定が必要である。そして、個人情報の委託に関する、委託目的の明確化、個人データの項目範囲、参照
等の利用する者の特定、参照者の目的、委託の取り消し要求が可能なこと等を、本人に通知す
る、または本人が容易に知り得る状態にすることが必要である。また、委託目的外の使用、指定参照者以外の参照、参照者の参照目的以外の使用は禁じられている。

③ 説明責任と啓発活動の重要性
個人情報保護に則った住民一人一人への対応と共に、生涯健康情報基盤において重要なことは、住民等との信頼関係であり、単に違反事象がおこっていないことを示すだけではなく、情報に関して安全管理が十分であることを説明できること、つまり説明責任を果たすことが求められる。具体的には、生涯健康情報基盤の運営主旨、運営体制、運営状況、プライバシー保護の状況について、住民に説明する機会を設けて理解を得ることが必要となる。そして、さらに次の段階では、生涯健康情報基盤の効果についてもオープンにして、住民参加の状態まで持ち上げることが望ましい。
38
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

（３） 情報参照権限について① データ参照者ごとのアクセス権限
アクセス権限の設定は、地域ごとの運用規定で決めるべきもので、固定的なルールは存在しない。
ここでは、一例として以下に述べる。
個人の健康情報にアクセスできるのは、本人、本人が指定した者、そして保健指導などの目的で前もって登録された自治体職員、保険者職員とする。本人が指定する者の代表例が、家族、診療中の医師、などである。
そして、前もって指定することができない医療機関、健診・保健指導機関、介護施設、民間事業者、などの利用場面では、原則、本人を目の前にして、本人が該当情報にアクセスして、検索結果を各施設で参照する方法とする。高齢者でＩＴ操作が難しい場合には、本人が持参するカード等（この意
味で社会保障カード等が望まれる）でアクセスできる対策を準備しておく。

② 救急時、災害時のアクセス権限
NW セキュリティプロジェクトにおいて検討されているので、そちらを参照願いたい。

（４） セキュリティ確保の仕組み
セキュリティ確保の仕組みは、組織的安全管理対策（体制、運用管理規定）、物理的安全対策、技術
的安全対策、人的安全対策、の全体がバランスよく実施されていることがポイントとなる。
その中の、組織的安全管理対策（体制、運用管理規定）、技術的安全対策について以下に述べる。

① 組織的安全管理対策（体制、運用管理規定）
安全管理について、従業者の責任と権限を明確に定め、安全管理に関する規定や手順書を整備し、その実施状況を確認しなければならない。組織的安全管理対策には以下の事項が含まれる。

ア）安全管理対策を講じるための組織体制の整備
イ）安全管理対策を定める規程等の整備と規程等に従った運用
ウ）健康情報取扱い台帳の整備
エ）健康情報の安全管理対策の評価、見直し及び改善
オ）事故又は違反への対処② 技術的安全対策
ア）セキュリティ確保の仕組み想定される脅威に対抗するために利用できる技術的対策の主なものとして、以下のものがある。技術的な対策のみでリスクをすべて防止できるわけではなく、運用管理による対策と併用することが必要である。
・利用者の識別及び認証・情報の区分管理とアクセス権限の管理
・アクセスの記録（アクセスログ）
39
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

・不正ソフトウェア対策
・ネットワーク上からの不正アクセスへの対策

イ）地域情報プラットフォームとの整合性
認証、暗号化、シングルサインオン、アクセス制御、などのセキュリティ技術については、
地域情報プラットフォームとの整合性が大切となる。

40
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

４ 導入推進体制の策定と導入計画
本章では、生涯健康情報基盤を先行して導入する場合の手順と、留意事項について述べる。

４．１ 導入推進体制の策定
生涯健康情報基盤の導入は、地域における保健医療介護福祉分野における業務プロセス改革（ＢＰＲ：Business Process Reengineering）の意味あいが多分にあり、計画遂行のためには強力なリーダシップが必要となる。以下は共同研究先での取り組みを参考にし、導入推進に最低限必要な組織、会議体について述べる。意思決定のスピードを考慮して、推進体制はできるだけ簡素、かつ責任と権限が明確になっていることが望ましい。
※業務プロセス改革ＢＰＲは、業務の進め方・流れを抜本的に見直し、無駄や非効率を改善して、合理化をすすめる活動を指す。

（１） 設立準備体制の立ち上げ
自治体内に生涯健康情報基盤の導入準備のための企画・計画を行う体制、例えば、生涯健康情報基盤設立準備チーム、または生涯健康情報活用推進班などを立ち上げる。
役割：自治体首長の指示のもとで、生涯健康情報基盤導入に向けた準備、プロジェクトの立ち上げ、プロジェクト運営事務局を務める．
重要な役割として、プロジェクト状況の広報、関係機関の調整の役割がある。
構成：関係部門（企画、健康増進課、国保保険課、介護保険課）などから、部門横断的にメンバー
選出することが望ましい。

（２） 生涯健康情報基盤システム推進委員会（仮称）等の立ち上げ
関係機関・団体の調整、コンセンサスの確立のため、コアとなる会議体として生涯健康情報基盤システム推進委員会（仮称）、そして特に重要なテーマである個人情報保護に関する意見調整、住民への説明資料等の作成のために、個人情報保護対策委員会（仮称）を立ち上げる。委員会形式で、関係機関・団体の代表、有識者、住民代表、等で構成され、合意形成のための会議体とする。実質的検討、資料作成は、下記の運営方針検討ＷＧ（仮称）、システム検討ＷＧ（仮称）とする。
事務局は、上記の設立準備組織とする。

（３） 運営方針検討ＷＧ（仮称）、システム検討 WG（仮称）の運営
全体プロジェクト構成は、できるだけ簡素にするのが望ましく、２階層とし上記推進委員会の下に、運営方針検討ＷＧとシステム検討ＷＧを設置する。自治体内に、要員・スキルが不足する場合にはWG メンバーの一部を外部に業務委託する方法もある。

① 運営方針検討ＷＧの内容
・運営理念、運営方針、運営目標、サービス内容、運営主体、運営体制、運営管理規定、等の検討、原案作成。
・個人情報保護対応の施策の検討と原案作成
41
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

② システム検討ＷＧ
・システム構築の基本方針、サービス内容詳細、システム外部仕様の検討、原案作成

４．２ 導入計画（１） マスタスケジュールの策定
自治体において生涯健康情報基盤を導入するスケジュールを決める際、国のＩＣＴ基盤の整備状
況を踏まえることが望ましい。オンラインレセプト、特定健診制度、そして社会保障カード（仮称）の整備､等である。
生涯健康情報基盤システムは既成のパッケージソフトウェアが世の中にまだ存在しない。そのため、まずは先行導入する自治体において、基本設計から開発、試験までの一連のシステム構築手順を推進する必要がある。従って、生涯健康情報基盤システムの基本サービス機能を、健診情報、診療情報（レセプト情報を含む）、災害医療情報、介護情報までの範囲で、システムを構築、情報整
備するには、図 ４-１に示すように３つの工期を組むことが考えられる。第１期から第３期まで、各工期において、設計工程、開発工程、そして試験工程が含まれる。

導入マスタスケジュール
第１期
特定健診
対応計画
オンライン
レセ対応計画

第２期

第３期

システム改修特定健診・特定保健指導の推進

平成２４年度までの結果評価

システム改修

健診情報とレセプト情報の分析▼平成２３年４月
原則オンライン

生涯健康情報基盤 プロジェク

住民コンセンサス
ト立上げ
情報化方針（推進委員会）

運用
開始

生涯健康
情報基盤

体制・基本設計
情報化全体設計（運営方針検討WG、システム検討WG）

健診・レセプト情報
災害医療
診療情報

介護情報

健診・レセプト情報・災害医療のシステム構築・整備

評価・改善

診療情報
の構築・整備評価・改善

介護情報の構築・整備

評価
・改善

健診情報
レセプト情報
診療情報
介護情報

図 ４-１ 導入マスタスケジュールの例

42
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

４．３ 導入予算・維持運営予算の項目策定
予算項目は、地域特性により差異があるため一概に決められるものではないが、考えられる予算
項目をモデル的に下記に列挙する。

（１） 基本構想策定の予算① プロジェクト立ち上げ費用
設立準備体制の立ち上げ、推進委員会、検討ＷＧの運営費用（会議室費、委員の交通費、印刷費、連絡費など）が必要となる。設立準備室の要員が自治体内部で確保が困難な場合は、外部からの要員派遣が必要となる。

② 基本構想策定業務委託予算（必要に応じて）基本構想案の作成を短期間に行う等の目的で外部に包括的に業務委託することを選択する方法がある。住民ニーズの確認、アンケート調査、関係機関・団体の意見収集とまとめ、システム
基本形態の策定などを一括して委託し、その結果を推進委員会などで検討し、報告書としてまとめる一連の仕事を業務委託するなどの方法案がある。

（２）システム構築予算
コンピュータシステム（ハード、ソフト、アプリケーション、システム構築費）の費用であり、契約形
態に買取、リース、レンタルがある。他に、ＡＳＰ（Application Service Provider）方式、業務の遂行および結果の責任までを包括的に外部に委託するアウトソーシング方式があるが、生涯健康情報基盤システムでは、まだ存在しない。
コンピュータシステムの他に、ネットワーク設備および回線費用がある。

（３）運営経費予算（毎年）
以下のような運営を行うための運営要員人件費と運営費が必要となる。

ア）委員会、評価委員会の開催
イ）普及広報活動ウ）会員管理（新規加入者の登録、非公開など）
エ）新規加入機関の呼びかけ、登録など
オ）システムの開発、運用、保守（データバックアップ含む）
カ）サポートデスク（住民、機関からの問い合わせ対応）
キ）制度変更への対応
ク）精度管理などデータの可用性確保ケ）システム障害対応

43
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

４．４ 先行導入計画における留意事項
先行導入計画における留意事項を、（１）地域特性の考慮、（２）段階的なシステム構築、について述べる。

（１） 地域特性の考慮
対象地域の規模および特性、予算から、生涯健康情報基盤構築の背景が異なる場合がある。例
えば、生涯健康情報基盤は住民サービスを中心に設計されているが、自治体と地域医師会との共同で、医療機関連携のサービスを追加する進め方なども想定される。その場合には、本書での基本サービス内容に、紹介・逆紹介のサービスを追加する形態で推進することで対応可能である。
また、特定健診制度対応の健診保健指導アプリケーションとのシステム連携を強化する等の改
善バージョンも考えられる。

（２） 段階的なシステム構築
生涯健康情報基盤システムのように、多くのステークホルダーが存在するシステムは、目的と効果が明確な部分から、小さく始めて成功体験を積み重ねるステップ・バイ・ステップ方式の手法が求められる。
計画は段階的構築の最終段階まで見渡したフル装備の計画とし、詳細設計以降の工程の着手を以下のように段階的に着手することを推奨する。

① 先行モデル地区
まずは、二次医療圏に相当する人口１０万人〜２０万人規模からスタートし、次のステップで地域を拡大する。

② システム対象範囲の段階的拡充
まずは、基本サービスで基礎を固め、その評価分析結果を踏まえて、より高度なサービスに着手する。

③ 収集、登録情報の段階的拡充
まずは、既に電子化されている特定健診・特定保健指導情報、レセプト情報からスタートし、次のステップで対象情報を拡大する。

④ 対象保険の段階的拡充、国保、健保、政府管掌など
まずは、地域の国民健康保険からスタートし、次のステップで他地域の国民健康保険、健康保
険組合、政府管掌保険へと拡大する。

44
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

５ 運用設計

５．１ 運用組織と体制について
本節では、生涯健康情報基盤の運用組織と体制について、その重要性の確認から事業推進にあたっての留意点について、考察する。

（１） 運営業務の内容と重要性
運営業務を項目化して以下に列挙するが、これらは、基本サービス実施時に必要な事項と発展段階で必要な事項に分類が可能である。また、アウトソーシングできる範囲とできない範囲にも分類できる。この分類は地域の状況によって異なるので、この分類や優先順位を検討することは、運営の効率化に影響するものと思われるため、よく吟味されることを望む。

①委員会、評価委員会の開催②普及広報活動③会員管理（新規加入者の登録、非公開など）④新規加入機関の呼びかけ、登録など⑤システムの開発、運用、保守（データバックアップ含む）⑥サポートデスク（住民対応、機関対応）⑦制度変更への対応⑧精度管理などデータの可用性確保⑨システム障害対応（２） 運用組織の考え方
運用組織と体制は、その地域特性や条件に適した形態を取るべきであり、当然多様なものとなる。
地域がそのあり方を構想するにあたり、どのような要件を考慮すべきかを考察する。
はじめに、地域による多様性を認めながらも、その前提となるべき生涯健康情報基盤の運用における必要条件、どのような組織体制であっても求められる要件は以下の３点が挙げられる。
ⅰ）公平性：生命・健康に関わる事業であるので、利用者が受益する内容に格差があってはならない。
ⅱ）正確性：同様に、運用における正確性は利用者の生命・健康に直結するものである。
ⅲ）守秘性：個人の健康・医療情報は最も守秘義務の高い機微情報である。
この 3 点は、本基盤が機微情報である個人情報を取り扱い、その情報は個人の生命と健康に直結するものであるため、運用に際して最低限担保されなければならない基本要件といえる。
45
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

運営主体としての組織体制は、行政（市町村・県）、民間企業、団体（財団法人など）、社会福祉協議会、医師会、ＮＰＯ法人などが考えられる。
これらの組織種別のいずれもが運営主体となることは可能であるが、それぞれの場合において
上記の３要件が担保できるか、言い換えれば地域住民への健康サ−ビスとして成立させ得るかを検討する必要がある。
第一に公平性については、法的基盤あるいは財源の透明性において、行政主体が最も適している。社協、医師会なども同様の特質を持つ。
第二に正確性については、市場原理が働く民間企業が技術面において優れると思われる。しかし正確性を担保する上での監視がなされるという意味で行政が勝ると考えられる。
第三の守秘性においては、第二の正確性と同様である。
この３要件を満たした上で、事業の継続性を考えなければならない。コスト管理と財源の確保が運営主体には求められるのである。この点では行政においては難度が高く、民間が有利と考えられるが、事業の理念に立ち戻ってみれば、そもそも生涯健康情報基盤は、地域住民全員を対象とするものであり、その住民個人の生活の根幹をなす健康増進を目的とするものである。したがって収益構造が発生しにくい、あるいは前提としない性質の事業と位置付けられる。このように考察すると、地域社会において基盤を構想するにあたっては上記３要件中の公平性を大前提とすべきであり、自治体が中心的役割を果たすことが妥当と思われる。
その上で、特に技術的な正確性や守秘性の向上を図るため、そして事業継続のためのコスト管理を徹底するためには、民間事業者などにアウトソーシングするというかたちが必然的に見えてくるものと思われる。そのスキーム構築にあたっては地域関係者間でのコンセンサス作りを、時間をかけて行なう必要がある。
（３） 運用組織と体制作りにおける留意点
生涯健康情報基盤事業の推進にあたっては、多数の関係者、機関の連携が必要となる。兵庫県
加古川地域での取り組み事例・ヒアリング結果などを参考にして留意点を抽出すると、以下の項目が挙げられる。

① 事業理念の確認
関係者、関係機関におけるコンセンサス作りが重要である。加古川地域では準備期間に 1000
回を超える委員会を開催したが、このような準備作業から円滑な運用を遂行できる組織・体制のイメージが醸成されてくる。

② 協力関係のルール作り
各役割の機能と権限、そして受益構造に関するルールを策定し、関係者間での認識を統一することが重要である。特に受益者負担については十分に検討すべきである。

③ 地域への説明作業
住民への周知・啓発活動、議会に対する説明、医療機関や事業者に対して効果を説明し参加を募る作業は、事業運営を継続させる基盤であり、恒常的に行なわれるべきである。
46
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

５．２ 運用継続性に関する検討
事業継続のためには、利用者の拡大、制度変更に対応したシステム改修、各種標準化対応、運営主体における人材確保、費用確保の課題が存在する。また、生涯健康情報基盤システムは、それを利用したことによる成果が出るまで長い期間がかかり、費用対効果がわかりにくいといった性格があり、そのことを踏まえた事前の対策をとる必要がある。
大きく運用継続性に関する課題を纏めると以下の３項目が考えられる。

ⅰ）利用者の普及・拡大に関して
ⅱ）サービス提供側の効率的な運営方法に関して
ⅲ）運用費用の確保に関して
上記３項目の対応策を一部ではあるが以下に記述する。

（１） 利用者の普及・拡大に関して運用を継続するにあたり、いちばんの課題は利用者の普及・拡大である。そのためには、２．３節で述べた住民向け健康情報サービスの各利用施設、および各家庭での利用環境の整備と広報活動が重要である。文字通りの「誰もが・いつでも・どこでも」利用できるサービスを定着させることである。評価の高い使用事例、評価委員会の中間報告などを題材に、地域の関係機関、団体への説明、現場担当者との意見交換など辛抱強い広報宣伝活動が大切となる。
そして、ある程度立ち上がりつつある状況を見極めて、次の段階として利用者拡大の環境を充実させる工夫が必要となる。例えば、インターネットに接続されたパソコンだけではなく、携帯電話等での利用を追加するとか、楽しく利用できる環境整備としてコンテンツ面での充実、サービスメニューの追加として例えば、住人参加型のサービスを盛り込むなどの施策がある。住民が健康に対して興味を抱くような内容をいかにして充実させるかが大切であり、さらに住民の健康意識の高揚を促し、行動変容をもたらす効果的な仕組みが必要である。将来的に考えられる住民向けの仕組みの一例
としては、グループダイナミックス効果をもたらすＳＮＳ的な仕組みなどが効果的であると考えられる。
※ＳＮＳ（Social Networking Service、コミュニティ型の Web サイト）
利用者の普及・拡大の解決策は前記のような対応策が考えられるが、普及拡大に関して情報弱者への配慮も必要であり、例えば高齢者向け健康教室において健康情報を活用する操作指導の時間を設けるなどの対策が必要となる。

（２） サービス提供側の効率的な運営方法に関して① 地域内関連機関との連携
特定健診データやオンラインレセプトデータなどの個人の健康情報を扱う機関･団体は、医療機関、健診機関、医療保険者、医師会、審査支払機関、介護関係機関、をはじめ地域に多数存在する。そのデータ蓄積および活用において、相互に連携することが効率化につながる。住民の47
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

健康増進という共通の目的のもとに、各機関、団体との相互運用メリットを明確にし新しいビジネ
スモデルを構築することが生涯健康情報基盤の運用の効率性を高めると考える。

② リソース共有による運用の効率化について
生涯健康情報基盤の運用においてはリソースの共有化による効率向上も重要となる。例えば、
データセンタについては、システム運用コストを考慮すると出来るだけ集中化することで効率化が図れる。各自治体のデータベースの独立性を担保しつつ、データセンタのリソースの共通化により、システムの運用、保守（データバックアップ含む）、サポートデスク（住民対応、機関対応）、制度変更への対応、システム障害対応、などがより効率的になる。
各自治体の生涯健康情報基盤システムが標準化されていると、リソースの共有化への移行が円滑でかつ効果も大きくなる。

③ 民間事業者との連携に関して
２．３節でも述べたが、生涯健康情報基盤のサービスには、自治体がサポートする「基本的サービス」と、どちらかと言うと民間事業者がサポートする比較的に「高度な選択的サービス」とからなっている。この両者の区分けは地域特性により差異があると考えられる。民間の市場原理に基づいた事業者サービスを育成することによって、健康情報の活用の場が広がり、生涯健康情報基盤が定着すると考えられる。
例えば、自治体と連携して民間事業者が、フィットネスクラブでの個人の健康情報に基づいた運動メニューの設定と効果測定などのサービスや、個人のバイタルデータや運動結果等の健康データを収集し自己健康管理に役立てるサービスを提供することが考えられる。その際、家庭においてはネットワーク接続可能な健康計測機器から自動的なデータ収集ができる仕組みの導入などが民間事業者からサービスされることが期待される。
地域の民間事業への働きかけや、セキュリティ担保のしくみづくり支援などが自治体・運用者に期待される。
この民間事業者、産業の育成により地域の活性化にも寄与することができる。

（３） 運営費用の確保に関して
運営費用の確保に関しては、地域特性により対応が異なると考えられる。ここでは考えられる
様々な方法を検討素材として列挙する。
・ 自治体が住民サービスとして自治体の全額負担で実施する。
・ 受益者負担として利用者（住民）の負担で実施する。
・ 関係機関・団体による費用拠出とする。
・ 医療保険者の一部負担。
・ 上記の各負担の組み合わせ。
48
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

６ 評価・改善の方法 （目標指標のモニタリングと改善案の検討）
６．１ 評価体制（１） 評価体制の必要性
少子高齢化の急速な進展に伴い、自治体を取り巻く環境は激しく変化している中で、生涯健康情
報基盤システムを導入することにより、着実に住民向けの保健・医療・介護・福祉サービスの向上を推進していく。各個別のサービスにおける効果や便益等を定期的に評価し、更に効果・便益が高まるよう施策の見直しを図っていくことが求められている。
各サービスの提供者や各サービス受益者が、進捗状況や効果等を評価することは、ある一側面からの見解となる可能性があるため、想定効果及び目標指標を独立した立場から具体的に評価する体制（評価委員会）が必要である。

（２） 評価委員会の設置① 評価委員会の役割
評価委員会では、「２．２課題の明確化と優先度設定」で抽出された課題を解決するにあたり、「２．５」で定義された指標を用いて、事業が計画通りに進捗しているか否かを評価することとなる。
具体的な各目標指標における評価手法等については、「６．２ 評価指標のモニタリング」で解説する。

② 基本的な評価方針
本節で提案する評価体制の基本的な評価方針を以下に示す。

ア）住民や利用者の視点からの評価に重点を置き、生涯健康情報基盤システムの効果を最大限引き出すこと。
イ）生涯健康情報基盤システムの活用を不断のものとするために、ＰＤＣＡサイクルの一層の定着を図る。
ウ）「見える化」等を通じ、オープンでフェアな活動を行う。
エ）「評価の３つの視点」を共通の認識として活動を行う。
【評価の３つの視点】○ 利用者・生活者の視点を堅持し、現地現物による確認に基づき、わかりやすく、利用者が恩恵を実感できる論点や指標を抽出すると共に、その「見える化」を行うことが重要である。
○ 非ＩＴ施策との一体的な施策の検討、評価が必要であり、周辺施策や制度慣習までメスを入れることが重要である。
○ ベンチマークで「相対評価」し、あるべき姿を「絶対値」で考え、そのギャップを「したいこと」「しなければならないこと」「今できていること」に分けて整理した上で、質・量・コスト・タイミ
ングの観点から評価することが重要である。
ＩＴ新改革戦略 第１回評価専門調査会より参照
49
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

③ 評価委員会のメンバー
ア）評価委員会のメンバー構成として、生涯健康情報基盤システムを十分に理解し、住民の意見聴取を実施するに際し、的確かつ客観性を持って市民の意見を取りまとめる議
長役の会長を設置する。また、会長を補佐し、会長に事故があるとき又は欠けた時のために、その職務を代理する副会長の設置が望ましいと考えられる。
イ）評価委員会のメンバーとしては、保健・医療・介護・福祉分野に見識があり、単に評価委員会に参加するだけではなく、保健・医療・介護・福祉分野の評価結果に対する意
見、保健・医療・介護・福祉分野に対する課題の提起等、積極的に取り組んで頂ける方を、有識者、住民から選抜する。
ウ）具体的な評価委員会のメンバーについては、地域特性に委ねるべきで一定の考え方は存在しないと考えられる。

④ 評価委員会の開催回数
生涯健康情報基盤システムにおけるサービスは、外部要因・内部要因の変化により重要性が低下したり、新たな必要性が生じたりする。そのため、評価委員会の開催は年に４回程度の開催
し、毎年繰り返し評価委員会を開催することが望ましい。各回で議論する内容（案）について以下に示す。
○ 第１回：モニタリング方法の確認・再検討（計画策定）○ 第２回：実施状況等の中間報告（モニタリング結果への評価と課題の抽出）○ 第３回：当該年度の成果報告と評価結果（課題に対する対策案の検討）○ 第４回：各サービス提供者へのフィードバック（対策の進捗状況の確認）

６．２ 評価指標のモニタリング（１） 定性的指標と定量的指標
本節では、「２．５想定効果創出に向けた目標指標の設定」で挙げた目標指標の中で、生涯健康
情報基盤システムの導入効果の評価にあたって、測定しやすいもの、導入効果を評価しやすいと考えられるものを取り扱う。
なお、本節で提示しているものについては、あくまでも一例であり、各地域特性を活かし、評価指標の設定を行うことが望ましい。

① 定量的な指標
ア）利用者数
生涯健康情報基盤システムの利用者は以下のように分類されるため、それぞれについて測定を行うことが望ましい。
・ 住民利用者数
・ 自治体（都道府県・市町村）における利用者数50
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

・ 健診、保健指導施設における利用者数
・ 医療機関（病院、診療所、調剤薬局）における利用者数
・ 介護サービス提供者（居宅介護支援事業所、地域包括支援センター）の利
用者数② 定性的な指標ア）効率性
生涯健康情報基盤システムの導入効果を測定する上で効率性を測定できる業務を以下に挙げる。
（自治体（都道府県・市町村））・

保健・医療計画等の計画書類の策定業務における効率

・

健康づくりにおいてネットワークを活用して限られたリソースの有効活用に役立っているか等（健診施設・保健指導施設（保健センター））
・

保健指導計画の策定支援における効率（介護サービス提供者）
・

ケアプランの作成、見直し業務の効率

イ）質的向上生涯健康情報基盤システムを導入することで、質に影響すると考えられる各サービスを以下に示す。
（自治体（都道府県・市町村））・ 疾病動向の把握における質的向上（健診施設・保健指導施設（保健センター））・ 個人に即した効果的な保健指導サービスにおける質的向上（医療機関）
・ プライマリ・ケア促進における質的向上
・ 救急医療の際の個人に最適な救急手段の選択における質的向上ウ）住民満足度
以下の住民満足度を把握することで、生涯健康情報基盤システムの評価を行えると考える。
・ 自己の健康情報を管理することに対しての満足度
・ 自宅等で自己の健康情報の変遷を把握できることに対しての満足度
・ 健康情報が各医療機関に正確に引き継がれていることに足しての満足度

51
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

（２） モニタリング方法
本節では、各評価指標におけるモニタリング方法について提案する。なお、ここで挙げるものは、
あくまでも一例であり、各地域特性を活かし、最善の方法を検討することを期待する。

① 定量的指標について
利用者数等の定量的な指標については、生涯健康情報基盤システムのアクセスログ等から分析を行うことが望ましい。なお、可能な範囲で詳細な情報を採取し、利用動向等を把握することで、今後のシステムの見直し時にも結果を活用することが可能である。

② 定性的指標について
定性的指標については、対象者によって多少調査方法が異なることが考えられる。そのため、以下に対象者ごとに、モニタリング方法の考え方を以下に示す。

ア）住民
生涯健康情報基盤システムを利用することでの各種サービスに対しての満足度を把握するにあたって、システム利用者に対してアンケート調査を実施することが望ましい。
なお、アンケート対象者をシステム利用者に絞る等、アンケート対象者の条件を詳細に設定し、対象者にアンケート用紙を郵送する方法などがアンケートの効率化になると考えられる。しかし、郵送のために氏名や住所といった個人情報が必要となるため、取扱いに注意が必要である。
イ）自治体（都道府県、市町村）
業務の効率化等これまで定量的に計測してきた事象や、サービスの質等これまで定量的に計測することが難しかった利用者の実感等をアンケート調査で把握することが望ましい。
なお、生涯健康情報基盤システムを導入することから生じる効果が現われるのに時間がかかる場合や、一時的な効果が発生する場合等も想定されるため、年に１回程度、数年にわたった継続的な観測が必要である。
ウ）医療機関、健診施設・保健指導施設（保健センター）、介護サービス提供者
自治体を対象としたアンケートと同様に、業務の効率化等これまで定量的に計測してきた事象や、サービスの質等これまで定量的に計測することが難しかった利用者の実感等をアンケート調査で把握することが望ましい。
なお、生涯健康情報基盤システムを導入することから生じる効果が現われるのに時間がかかる場合や、一時的な効果が発生する場合等も想定されるため、年に１回程度、数年にわたった継続的な観測が必要である。また、職種（経営者、医師、医事課職員）
によって実感が異なる場合も想定されるため、職種毎のアンケート調査が必要である。

52
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

（３） 制度の効果とＩＣＴ活用の効果の分離
生涯健康情報基盤システムを導入したことによる、想定効果及び目標指標を独立した立場から具体的に評価するにあたって、生涯健康情報基盤システムを導入したことによる効果であるか、又は、制度自体の効果であるかを区別して評価する必要がある。制度による効果ではなく、生涯健康
情報基盤システムを導入したことによる効果を浮き彫りにするには、同一地区のモニタリングだけでは不十分であり、健康情報基盤システム等、ＩＣＴを導入していない地区との比較が重要である。

（４） 効果等の外部提供
現在、生涯健康情報基盤システムは、発展途上であり、今後、各種議論を重ね、よりよいシステ
ムとしていく必要があると共に、本システムの効果や課題等についても、他自治体に対して、普及
啓発的な意味合いも込めて、ホームページ等を介して情報公開を行っていく必要がある。
そのため、評価委員会等で取りまとめた、当該年度における効果や課題、若しくは多年度にまたがる時系列的な効果についても、随時、外部に情報発信・提供していく必要がある。

６．３ 改善方法（１） 改善策の策定① ＰＤＣＡサイクルの実行
継続的に生涯健康情報基盤システムを活用していく上で、ＰＤＣＡ（ＰＬＡＮ（計画）−ＤＯ（実施）−ＣＨＥＣＫ（評価）−ＡＣＴＩＯＮ（調整・改善））のマネジメントサイクルを円滑にまわすことが重要である。各フェーズで行う内容について以下に示す。

ア）PLAN
事業の全体的なバランスや、各サービスの重要性・実現可能性などを勘案し、次年度に行われる実施計画を策定する。
イ）DO
実施計画に基づき、各サービス主体において、目標の達成を目指して着実に事業を実施する。
ウ）CHECK・・・評価委員会にて支援
当年度に実施されたサービスに対し、実施計画（想定効果や評価指標）に基づいて評価する。評価委員会にて、事業が適切に実施されているか否かを評価する。
エ） ACTION・・・評価委員会にて支援
各サービスの評価結果は各サービス提供者にフィードバックされ、評価委員会にて、事業の見直しや改善策の検討などを行う。検討結果は各サービスの実施計画の原案としてとりまとめ、次年度へと反映させていく。

53
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

C

評価委員会

C

C

D

実行

評価

P

進行管理を通じた
生涯健康情報基盤システムの継続的な活用の継続的な活用

D

A

実行

見直し
改善 改善策の検討

評価

P

評価

D

A

実行

見直し
改善策の検討

改善

A

P

改善

計画

計画

計画

住民向けの
保健・医療・介護・福祉
サービスの充実

図 ６-１ ＰＤＣＡサイクルのイメージ

54
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

７ 平成２０年度に向けて

平成２０年度は対外的な啓発活動を継続すると共に、生涯健康情報基盤（ＥＨＲ）基本提案書（第２版・詳細版）を作成する。
生涯健康情報基盤に関心があり先進的な取り組みを志向する自治体との共同研究、実証事業などを通して、現場の具体的なニーズ・要件・実現方法などを整理し、提案書を詳細化する。

55
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

ＥＨＲ（健康領域）プロジェクト 構成員一覧

表 ７-１ ＥＨＲ（健康領域）プロジェクト 構成員・オブザーバー 一覧（５０音順）

構成員
プロジェクトメンバ

役 割

秋田県

メンバー

秋田県横手市メンバー

ＮＰＯ法人医療ネットワーク情報センター

メンバー

株式会社エスビーエス情報システム

メンバー

エヌ・ティ・ティ・コミュニケーションズ株式会社

メンバー

エヌ・ティ・ティ・ピーシーコミュニケーションズ株式会社

メンバー

財団法人加古川総合保健センター

メンバー

株式会社サイバーリンクス

メンバー

東京都中野区メンバー

富士通株式会社リーダー

株式会社富士通総研

メンバー

マイクロソフト株式会社

メンバー

株式会社三菱総合研究所

メンバー

オブザーバー総務省

以上

56
Copyright（C） 2008, The Association for Promotion of Public Local Information and Communication

別添資料「住民向け健康増進アプリケーションの検討」〜生涯健康情報基盤（ＥＨＲ）〜

平成２０年３月（財）全国地域情報化推進協会
ＥＨＲ（健康領域）プロジェクト
Copyright（C） 2007, The Association for Promotion of Public Local Information and Communication

目次

１．ＡＰＰＬＩＣ及びＥＨＲプロジェクトの紹介
２．医療健康分野を取り巻く環境
３．政府の動向
４．地方公共団体様のニーズと課題
５．解決の方向性
６．ＩＣＴ利活用の先進事例
７．医療健康分野のＩＣＴ利活用に向けて
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

2１．ＡＰＰＬＩＣ及びＥＨＲプロジェクトのご紹介

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

3

ＡＰＰＬＩＣ（(財)全国地域情報化推進協会）※APPLIC：The Association for Promotion of Public Local Information and Communication

会員数

自治体/個人会員:351, 企業(普通)会員:147, 企業(賛助)会員:107 合計:605（平成20年2月末日現在）■ミッション
公共ネットワークの活用

地域情報化の普及促進

公共ネットワークの構築

地域情報プラットフォームの構築(標準仕様作成・管理)

地域CIO育成(e-ラーニング、集団研修等)

地域公共ネットワークの整備促進

レガシーシステムの移行モデルの確定

地域情報化ナレッジライブラリの構築・運用・管理

公共ネットワークの相互接続の推進(仕様作成・管理)

全国公共アプリケーションの整備(防災・医療・教育分野等)

地域情報化に関する各種セミナー等の開催

全国公共ネットワークの整備促進

高付加価値サービスの普及促進（官・民連携仕様に準拠した自治体システムや民間サービスの活用）
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

4

ＡＰＰＬＩＣ（(財)全国地域情報化推進協会）■目指す地域像

地域情報プラットフォーム
公共ネットワークの構築
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

5

ＥＨＲ（健康領域）プロジェクト※ＥＨＲ＝Ｅｌｅｃｔｒｏｎｉｃ Ｈｅａｌｔｈ Ｒｅｃｏｒｄ

地域情報プラットフォームをベースとし、ＥＨＲをコアとした健康情報活用基盤のあり方を国及び自治体･地域住民視点で要件
自治体に提言をとりまとめた健康情報活用
健診情報
レセプト情報基盤のモデリング提案
診療情報

ＥＨＲ
住民
健康情報活用基盤

他自治体［高信頼性通信］

医療・健康
介護・福祉

業務Ｂ

業務Ａ

住民記録

地域ポータ
ル

［高セキュリティ］［Ｗｅｂサービス連携］

地域情報プラットフォーム
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

6

プロジェクト活動の今年度目標
国民が安心して活躍できる健康長寿社会の実現
共同研究（秋田県様、加古川総合保健ｾﾝﾀｰ様）
基本提案書（課題と実現方法）
コンセンサス作り

標準化

個人情報保護

ICT活用

運用コスト

地域情報ﾌﾟﾗｯﾄﾌｫｰﾑ

普及啓発活動APPLIC主催
セミナー
地域ＩＣＴ活用
セミナー「生涯健康情報基盤システム」の自治体への提言
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

7

検討体制
（１）医療・健康・福祉WG検討体制（２）医療・健康・福祉WG構成員一覧

アプリケーション委員会
オブザーバ
総務省 地方情報化推進室
情報流通高度化推進室
厚生労働省 医政局医療機器情報室
老健局介護保険課

秋田県

副主査

京都府

副主査

長野県

副主査

和歌山県

副主査

アドバイザ

千葉県市川市副主査

岩手医科大学
澤井高志 教授
大田原赤十字病院 水沼仁孝 医師
琉球大学
吉見直己 教授

東京都中野区

副主査

東京都三鷹市副主査

秋田大学付属病院 近藤克幸 教授
東京大学付属病院 奥真也 准教授
九州大学付属病院 中島直樹 講師

独立行政法人情報通信研究機構
ＮＰＯ法人医療ネットワーク情報センター
株式会社内田洋行
株式会社エスビーエス情報システム
ＮＥＣネッツエスアイ株式会社
エヌ・ティ・ティ・コミュニケーションズ株式会社

医療・健康・福祉WG
医療・健康・福祉WG

株式会社エヌ・ティ・ティ・データ

主査 ： 東京大学大学院情報学環 山本隆一 准教授

副主査

株式会社エヌティティピーシーコミュニケーションズ
財団法人加古川総合保健センター
株式会社コミューチュア
株式会社サイバーリンクス

介護ＮＷサービスPT
ﾘｰﾀﾞｰ：日立製作所
NTTｺﾐｭﾆｹｰｼｮﾝｽﾞ
ＮＴＴデータ富士通
富士通総研

ＥＨＲ（健康領域）PT
ﾘｰﾀﾞｰ：富士通
秋田県
東京都中野区
秋田県横手市
加古川総合保健ｾﾝﾀｰ
ｴｽﾋﾞｰｴｽ情報ｼｽﾃﾑ
サイバーリンクス
NTTｺﾐｭﾆｹｰｼｮﾝｽﾞ
ＮＴＴデータＮＴＴＰＣｺﾐｭﾆｹｰｼｮﾝｽﾞ
富士通総研
マイクロソフト三菱総合研究所

ＮＷセキュリティ PT(災害時医療支援ＰＴ)
ﾘｰﾀﾞｰ：NTTデータ
ｴｽﾋﾞｰｴｽ情報ｼｽﾃﾑ
NTTｺﾐｭﾆｹｰｼｮﾝｽﾞ
コミューチュア
三菱総合研究所

シスコシステムズ株式会社
日本電気株式会社
日本アイ・ビー・エム株式会社
日本オラクル株式会社
社団法人日本ケーブルテレビ連盟
東日本電信電話株式会社
株式会社日立製作所

副主査

株式会社日立中国ソリューションズ
富士通株式会社

副主査

株式会社富士通総研
マイクロソフト株式会社
株式会社三菱総合研究所
山本 隆一（東京大学大学院情報学環 助教授）

主査

31団体

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication8

２．医療健康分野を取り巻く環境

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication9高齢化率と医療費の動向
２００５年度の国民医療費は３３．１兆円。毎年約１兆円の伸び。老人医療費の占める割合は増加しており、２０年後には国民医療費の半分を占めると予想される。
兆円

60.0

29%

２００５年度 国民医療費 ３３．１兆円

56

増加 1兆円の７５％が老人医療費（※）
23%

45.0

高齢化率（％）

15%

30.0
10%

27.0

16%

17%

15%

16%

28.5

28.9

29.6

30.7

17%
30.1

16.0

18%

19%

19%

31.1

31.0

31.5

33.1

8.9

9.7

10.3

10.9

4.1

11.8

11.2

11.7

11.7

10%
11.7

老人医療費（兆円）

0.0

0%
20
25

20
03

20
02

20
01

20
00

19
99

19
98

19
97

19
96

2005年度

19
95

19
85

20%

40

国民医療費（兆円）

20
15

15.0

30%

※老人医療費は、２００２年度の制度改正により、対象年齢が７０歳以上から段階的に引き上げられており、２００５年は７３歳以上を原則とする。
参考：総務省統計局『統計データ〜人口推計』 ／国立社会保障・人口問題研究所『日本の将来推計人口（中位数）』
厚生労働省大臣官房統計情報部編『厚生統計要覧 平成17年度』／厚生労働省『医療制度改革大綱による改革の基本的な考え方』
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication10

世界で最も急速に高齢化
65歳以上の人口割合
65歳以上の人口割合
50年後には65歳以上の人口割合が現在の２倍近くに
（％）

40

1950
2000
2050

35
30
25
20
15
10
5

カ
リ
メ
ア

ア
リ
ラ
ト
ス
ー
オ

国
中

ダ
ナ
カ

ス
リ
ギ
イ

国
韓

ン
デ
ー
ェ
ウ
ス

ツ
イ
ド

本
日

0

出典：World Population Ageing 1950-2050
Population Division, DESA, United Nations, 2002

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

11

英国イングランドの取り組み（Ｃｏｎｎｅｃｔｉｎｇ Ｆｏｒ Ｈｅａｌｔｈ）
NHS（National Health Service）による医療サービスの提供
プライマリケア(GPs：General Practitioners）と第二次診療(病院専門医）による医療サービス体制

英国の医療の抱える問題点
国による医療費の予算統制 → 入院待機者の増大、医療サービス水準の低下
データ不足による誤診療の防止
ITの利活用による効率化（２００２年〜）
イングランドを５つの地区にわけ、地区ごとにﾛｰｶﾙｻｰﾋﾞｽﾌﾟﾛﾊﾞｲﾀﾞを設置、IT化を推進
富士通サービスがイングランド南部地区を担当

国民

予算 ： ３〜６兆円 （１０年）
検査技師等
5万人

看護師
38万人

GP／専門医を問わず、英国のどの診療所・病院からでも瞬時に患者の診療情報にアクセス可能
医師
10万人

カルテ情報／診療予約／紹介状／画像等の情報を交換・共有
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

12米国の取り組み（ＯＮＣＨＩＴ）※Office of National Coordinator for Health Information Technology

ブッシュ大統領命令 2004年（年頭教書で指示）10年以内にすべての国民が個人の電子カルテを持つべきである− 詳細は2004年4月26日 AACC（American Association of Community Colleges）総会 −米国の医療の抱える問題点
・ 適正な医療情報の不足などが原因による死亡 (44,000〜98,000人／年）
・ 医療費の増加（健康保険費用は過去3年間、年10％以上増加）
・ 重複検査（全体の17％〜49%が重複と見られる）・ 全国的な監視システムの欠如 （新興伝染病、医薬品副作用、生物兵器テロ対応）

米国保健省ＨＨＳの下に推進組織ＯＮＣＨＩＴ※1：Regional Health Information Organization※2：National Health Information Network※3：Health Information Technology Standards Panel・全アメリカ国民のための個人電子カルテ １０ヵ年計画の作成
・地域単位で医療機関が患者個人の医療情報を継続的に
民間ベースの共有・交換できる仕組みを構築 ＲＨＩＯとＮＨＩＮ
・ＨＩＴＳＰ：標準を組み合わせてオーソライズする組織

医療ＩＴ化

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication13

カナダの取り組み （Ｉｎｆｏｗａｙ）
EHR開発推進組織としてInfowayを設立、2009年末までに50%普及（政府・州の折半出資1000億円、非営利組織、Canada Health Infoway Inc. 2001年設立）

カナダの医療の抱える問題点
医療費の増加、GDP比 10〜11% （州と政府の財政圧迫）
適切な情報がないために診療現場で死亡することを防止、広大な国土と遠隔医療のニーズ
ＥＨＲ導入効果：いつでも、どこでも必要な時に医療情報にアクセス可能！
EHR SOLUTION (EHRS)

EHR SOLUTION (EHRS)

EHR INFOSTRUCTURE (EHRi)

EHR INFOSTRUCTURE (EHRi)

PublicHealthService

Data

EHR

PublicHealthService

Registries

Warehouse

ＬＲＳ： Longitudinal Record Services

医療機関

医療機関
Application

EHRS

EHRS

EHR

国レベルの接続

Registries

Warehouse

ＬＲＳ：Longitudinal Record Services

ＨＩＡＬ： Health Information Access Layer

Application

Data

各州のEHR

各州のEHR

医療機関

医療機関

ＨＩＡＬ：Health Information Access Layer

EHR
Viewer

EHRS

EHRS

医療機関

医療機関

Application

Application

EHRS

EHRS

EHR
Viewer

EHRS

州とＩｎｆｏｗａｙの共同プロジェクト１９７箇所進行

３階層構造でカナダ全土をサポー

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

14

生活習慣病の有病者の状況 （日本）
生活習慣病の国民医療費に占める割合は約３割超（約１０．４兆円）を占め、死亡原因でも約６割を占める。

平成１９年版厚生労働白書 ３０ページ（図表２−１−３）
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

15

３．政府の動向

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

16

政府の施策
医療制度改革関連法 （2006.6 通常国会にて成立）
・ 生活習慣病予防への本格的な取組み→ 健診・保健指導の義務化、 都道府県医療費適正化計画策定
・ 患者本位の医療提供体制の実現→ 入院から在宅医療まで地域医療機能の分化・連携を推進
・ 後期高齢者医療制度の創設

ＩＴ新改革戦略 （ＩＴ戦略本部 2006.1.19閣議決定）−ＩＴによる医療の構造改革−
・ ﾚｾﾌﾟﾄの完全ｵﾝﾗｲﾝ化 (2011年完了目標)
・ 統合型医療情報ｼｽﾃﾑを200床以上の病院に導入（2010年度まで）
・ 生涯を通じた健康管理→ 電子健康情報を活用するための基盤整備(2008〜2010年)
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication17

健康情報基盤の実現（ＩＴ新改革戦略）①個人の健康情報を自らが管理し医師、保健師等に提示できる②異なる保健医療福祉機関においても患者の健康情報が分断されない継続性③疾病情報や臨床データの分析による根拠に基づいた保健医療福祉サービス
そのため、健診結果等の健康情報を個人が活用するとともに全国規模で収集・分析する仕組みを２０１１年度当初までに構築する。

ＩＴ新改革戦略 政策パッケージの概要について 平成１９年４月５日 ＩＴ戦略本部
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication18

健康情報基盤のための環境は整いつつある（１）オンラインレセプト（２）特定健診制度（３）社会保障カード（仮称）（４）３省連携の健康情報基盤整備事業（５）医療情報の外部保存ガイドライン

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

19

４．地方公共団体様のニーズと課題

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication20

アンケート調査の報告（抜粋）「保健・医療分野に関する自治体の意識・課題を調査」
対象

ＡＰＰＬＩＣ地方公共団体会員 ２３０団体（４７都道府県、１８０市区町村）

実施期間

平成１８年１２月２２日〜平成１９年１月１５日

手法

メール（APPLIC事務局からメールし回答受信）

回収率

都道府県
市区町村

設問内容

基礎データ（５問）、現状の取り組み（１１問）、今後の取り組み（５問）、その他（４問）
合計：２５問

４４．７％（２１地方公共団体）
３９．４％（７１地方公共団体）

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication21

アンケート結果要旨
１．自治体における医療・健康施策の中での最重要分野① 「予防」、「健康増進」が７５％以上であり、早期発見、治療、 フォローの合計よりも多い。
２．電子的情報を活用した医療・健康の住民サービス① 現状 「ホームページでの情報提供」（８０％以上）を実施。
② それ以外の計画がなく、課題が浮き彫りになった。
３．生涯健康情報を住民に提供する際の課題① 推進体制（２１％）② 個人情報保護対策（２２％）③ 予算／財源（２４％）
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

22生涯健康情報を住民に提供する際の課題（アンケート詳細）
複数回答 ２２４件

複数回答 ５１件
2.0 %
9.8 %

国からの指針ﾃﾞｼﾞﾀﾙﾃﾞﾊﾞｲﾄﾞ対策

6.7 %
7.1 %

効果的ｱﾌﾟﾘｹｰｼｮﾝ

8.9 %

予算・財源

24.1 ％

ＩＴ人材

9.4 ％

個人情報保護対策

21.9 ％

推進体制の整備21.4 ％

17.6 ％

市町村

都道府県

9.8 %
9.8 %
19.6 ％
11.8 ％
19.6 ％

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication23

秋田ヒアリングについて（共同研究） ①□第一次ヒアリング
・期間 平成１９年７月３１日〜８月２日
・ヒアリング先
地方自治体３カ所、健診団体２カ所、医療機関１カ所□第二次ヒアリング
・期間 平成１９年８月２２日〜８月２３日
・ヒアリング先医師会２カ所、健康保険組合２カ所、審査機関１カ所

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication24

秋田ヒアリング要旨 ②
生涯健康情報を住民に提供する際の基本的考え方（１）個人の健康情報（保健、医療、福祉に係わる情報）の集約を基本に、地域の住民の健康づくりを支援するシステムである。従って、保健、医療、福祉の各サービス提供機関との連携のもと、住民の立場に立って一貫したサービスを提供できることが重要であり、施設および医療保険者にとらわれない広域情報、かつ長期の情報が揃っていることが望ましい。
（２）特に、保健分野の健診、保健指導情報については、生活習慣病の予防という観点から住民が自らの健康情報にアクセスし健康管理に活用する手段をサポートすることが望ましい。
（３）医療情報と健診、保健指導情報がシームレスに見られることで、診断の精度および、保健指導の効果は向上すると考えられる。健診結果と医療機関での検査結果の一連性の確保が望ましい。
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication25

秋田ヒアリング要旨 ③
健診情報についての要件整理（１）特定健診・特定保健指導の他に、人間ドッグ、がん検診、等も含めること、また乳幼児健診、学校健診から特定健診までの一連のデータが揃っていることが望ましい。
（２）メタボリック対策だけでなく、地域特性に応じて脳卒中、高血圧など対象を広げられること。
（３）経年的、時系列表示を示し、同年代の全体での位置付けを提示
し、個人が自分の立場、位置を理解し、生活習慣病予防のための行動変容トリガとなることが望ましい。
（４）特定健診、特定保健指導と行動変容の情報を蓄積することにより、有効性の確認と地区別疫学統計が可能となること。

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication26

秋田ヒアリング要旨 ④
医療情報についての要件整理
・住民サービスとして、医療機関を越えて利用性の高い情報から集約対象とすべきである。
（例）現病名、既往歴、家族歴、禁忌・アレルギー情報、服薬情報、検査結果、
画像検査結果、予防接種歴、等

セキュリティ・プライバシー
・健康情報は個人情報であり、集約収集および閲覧については、
原則本人の同意が必要である。
・主旨、情報の範囲、利用目的等について十分に住民の理解を得られた状態にすることが大切である。

標準化
・健診データの様式を統一し、情報を指導や診療の目的に沿って分類し、団体に拠らず統一感のある表示様式にする必要がある。
・検査結果値の標準化（精度管理）も重要である。
・共有する基本的な診療情報は標準化が必要である。
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication27

秋田ヒアリング要旨 ⑤
推進にあたり・ＩＣＴ導入の経済的な有効性等を明確にする必要がある。
・都道府県・市町村レベルでの条例等（自治体における情報管理のセキュリティ担保、など）の整備の検討が必要である。
・収集した情報の利用目的を明確化し、情報の取り扱い者、範囲等を整理する必要がある。

運営主体と事業の継続性（利用者負担）
・運営主体については地域特性に委ねるべきである。行政の主導、また地域の関連機関との協力体制など種々の形態が考えられる。
・利用促進の立場からは住民負担なしが望ましい。運営コスト捻出から一部利用料を徴収することを考慮する余地はある。その場合でも、コストと行政負担などの折り合うところで、できるだけ低額が望ましい。
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication28

５．解決の方向性

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication29

目指すべき社会
国民が安心して活躍できる健康長寿社会の実現
いつでもどこでも受けられる医療体制づくり
・地域中核病院整備
・高度医療や救急医療
広域整備

医療分野
国民が地域で安心して医療サービスを享受できる
社会

生涯を通じた健康づくり
・生活習慣病予防
・高齢者健康づくり

健康分野
国民自らが自発的に健康増進に取り組む社会

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication30

自治体における課題、ニーズの分析 ①
都 道 府 県＜ 情 報 ＞
科 学 的 根 拠 に 基 づ く地 域 保 健 の 推 進
地 域 の 保 健 医 療 情 報 の 把 握集約された課題、ニーズ＜ 人 ＞
市 町 村 へ の 専 門 的 、技 術 的 支 援
地域保健対策に係る人材の 確保育成
地 域 住 民 へ の 啓 発＜ そ の 他 ＞

住 民 ひ と り一 人 の 健 康 情 報 に 基 づ
い た 保 健 医 療 サー ビ スの 提 供
デ ー タ に 基 づ い た 保 健 医 療 介 護 施
策 の 策 定各 種 計 画 の 企 画 及 び 調 整
市 町 村 及 び 医 療 機 関 、 保 険 者 協 議会 等 の 関 連 団 体 との 連 絡 調 整

市 町 村＜ 情 報 ＞
健 診 情 報 の 医 療 と保 健 の シ ー ム レス な
情報共有

専 門 的 な 知 識 に 基 づ い た 施 策 の 円
滑 な 実 施行 政 及 び 医 療 機 関 、保 険 者 協 議 会
等 の 関 連 団 体 との 連 絡 調 整

人 材 確 保 ・育 成

健診情報の 時 系列的な 情報管理
情 報 開 示 に よ る 安 心 ・ 安 全 な 医 療 ｻ ｰ ﾋ ﾞｽ

＜ 人 ＞
制 度 改 正 に よ る 役 割 ・体 制 の 見 直 し＜ 金 ＞
国 民 健 康 保 険 、 介 護 保 険 の 支 出 の
抑 制
患者の 適正な 医療費負担下の サ ービ ス 提供

生 活 習 慣 病 対 策 の 定 着 と成 果 の 管理
高 齢 化 社 会 に 対 応 した 健 康 情 報 の蓄 積
健 診 及 び 医 療 ・介 護 情 報 の 共 有 と公 開＜ そ の 他 ＞
各 種 計 画 の 企 画 及 び 調 整
都 道 府 県 との 連 絡 調 整
福 祉 行 政 、 特 定 健 診 ・保 健 指 導 、 各
種 保 険 事 業 、衛 生 行 政 等 の 実 施
医 療 機 関 、 保 険 者 協 議 会 等 の 関 連
団 体 との 連 絡 調 整
災 害 ・救 急 時 に お け る 迅 速 な 搬 送 ・治療

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication31

自治体における課題、ニーズの分析 ②
高い

エリアＢ

エリアＡ

データに基づいた保健医療介護施策の策定
データに基づいた保健医療介護施策の策定

サービスの﹁質の向上﹂
低い
低い

住民ひとり一人の健康情報に基づいた住民ひとり一人の健康情報に基づいた保健医療介護サービスの提供
保健医療介護サービスの提供

高齢化社会に対応した健康情報の蓄積
高齢化社会に対応した健康情報の蓄積
健診及び医療・介護情報の共有と公開
健診及び医療・介護情報の共有と公開
人材確保・育成
人材確保・育成

生活習慣病対策の定着と成果の管理
生活習慣病対策の定着と成果の管理

行政及び医療機関、保険者協議会等の関連
行政及び医療機関、保険者協議会等の関連団体との連絡調整団体との連絡調整

エリアＤ
根っこは一つエリアＣ
専門的な知識に基づいた施策の円滑な専門的な知識に基づいた施策の円滑な実施
実施

個人の健康情報を長期にわたり収集し、コンピュータ
処理可能な形式で保存し利活用できるしくみが必要
サービスの「効率性」

高い

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

32

生涯健康情報基盤（ＥＨＲ）は人とシステムの融合体
生涯健康情報基盤
生涯健康情報基盤システム

運営理念

情報の維持・閲覧

運営目標

匿名化
情報

健診

利用施設

医療
自治体

運営体制

介護
情報の登録

運営管理規則委託

運営資金

住民（個人）

地域包括支
援センター等

医療機関

診療

介護など

医療保険者

健診・レセプト

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

33

自身の健康情報にいつでもどこでもアクセス可能
情報管理センター
匿名ＤＢ

診療情報
中核病院

遠

クリニック
隔

生涯健康
医療情報
ＤＢ

生涯健康情報基盤

診
療

診療情報

へき地診療所

健診機関
健診情報
ﾚｾﾌﾟﾄ情報

医療

薬

保健所

服薬履歴

保健福祉

介護・福祉

（投薬情報）

薬局

人間ドッグ

情報セキュリティ、
ネットワークセキュ
リティの確保

地域包括支援センター

介護（予防）
サービス事業者

給付管理票
ﾚｾﾌﾟﾄ情報Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication34

自治体における健康情報の活用
情報を電子的に収集

住民のライフステー
ジに応じた行政サー
ビスの企画・提供

情報変更

医療・健康・
福祉サービスの質の向上

生涯健康情報データベース

情報
評価

収集

発生源の異なる
データの統合／蓄積

蓄積

住民満足度の向上
活用

分析結果の活用分析

蓄積データの分析

根拠に基づき、限られ ヒト（医師、看護師、保健師等）
た地域リソースの適正モノ（病院、健診施設、介護施設等）
な配分・配置カネ（予算、補助金等）
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication35

生涯健康情報基盤の３つのサービス内容
生涯健康情報基盤（ＥＨＲ）
住民の健康情報（健診情報、レセプト情報、診療情報、介護・福祉情報等）の収集・維持・閲覧の機能
住民向け健康情報サービス
いつでもどこでも必要な時に自身の健康情報を参照・活用
災害医療・救急医療におけるＩＣＴ支援サービス
個人の健康情報のなかで最低限必要な情報に現場の医療従事者がアクセスできる
健康推進施策の策定、啓発活動支援サービス
地域単位の統計情報・疫学情報の提供
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication36

「基本的サービス」「より高度な選択的サービス」の例※ 明確な区分けはない、また地域特性、方針によりどこまでを基本とするかが変化する。
基本的サービス

より高度な選択的サービス

住民向け健康情報サービス

個人の健康情報の収集・
維持・閲覧

家庭におけ
る測定デー
タの登録

保健師によ
る観察・指
導サービス

災害医療・救急医療におけるＩＣ
Ｔ支援サービス

災害・救急時用
健康情報の収集・維持・閲覧

モバイル
閲覧機能

救急処
置結果
の登録

健康推進施策の策定、啓発活動支援サービス

保健医療福祉サー
データマイニビスの状況把握
ング機能
データ抽出

・・・

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication37関連する他システム

この部分の構築を提言している

生涯健康情報基盤
運営理念

紹介・逆紹介システム
遠隔画像・病理診断システム

生涯健康情報基盤システム

運営目標

情報の維持・閲覧

運営体制

利用施設

運営管理規則

自治体

匿名化
情報

健診

・・

地域連携パス・システム

医療地域包括支援センターシス
テム

介護
情報の登録

運営資金

基本サービス（コア）・・
自己健康管理支援シ
ステム

委託
住民（個人）

比較的に高度なサービス（オプション）※ 民間事業者による運営が望ましい

医療機関
診療

病院情報システム

地域包括支援センター
介護など

等

介護事業者システム

人間ドック、事業者健診、生活機能評価シス
テム

医療保険者
健診・レセプト

特定健診・保健指導システム

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

38

実現イメージ（モデル構成）①
生涯健康情報基盤システム
テーブル& マスター
各種マス
ターと
コードテー
ブル

住民基本情報サービス
住民属性
情報

健診・保健
指導情報

保険情報

アクセス権
限ルール

健康施策・疫学統計

住民ごとの健康情報＆サービス

EHR
インデックス

メッセージ
構成情報

診療
情報

レセプト
情報

介護・福祉
情報

匿名化
情報

データベース
様式情報

生涯健康情報の収集・参照サービス
認証キー
情報

環境記述
Config

共通通信サービス
通信サービス

通信サービス

通信チャネル

匿名化情報

利用施設

保健指導
サービス

本人

医療機関
受診

本人

介護事業者
など

本人

自己健康管理本人(自宅から)

災害医
療救急
医療

災害時医師

保健行
政医療
計画

自治体職
員

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

39

実現イメージ（モデル構成）②
他の都道府県

都道府県単位のデータ管理運営センター
他地区
連携

住民ごとの健康情報＆サービス

住民基本情報サービス

健診・指導
レセプト
介護福祉

住民属性
・保険情報

診療
情報

大規模市町村匿名化
情報他県・大規模
市町村
生涯健康情
報基盤

EHR
インデックス
共通通信サービス
通信サービス

共通通信サービス

健診・
保健指導

レセプト

市町村 Ａ

通信
サービス

通信チャネル

介護福祉

共通通信サービス

・・・

健診・
保健指導

レセプト

介護福祉

市町村 Ｂ

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

40

６．ＩＣＴ利活用の地域先進事例

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication41

加古川地域の事例① （加古川地域の概要）
構成
人口
医師会
医療機関数
基幹病院

：一市二町
｢加古川市・加古郡稲美町・播磨町｣：約33万3千人：加古川市加古郡医師会(一市二町の行政エリアと同一)：198ヶ所（内参画医療機関は118ヶ所）：兵庫県立加古川病院
加古川市民病院
甲南加古川病院（旧国立加古川病院）
神鋼加古川病院

財団法人加古川総合保健センター（昭和55年10月 一市二町・医師会の共同出資）
行政立機能 ：地域住民の健診センター
医師会立機能 ：臨床検査センター

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication42

加古川地域の事例② （プロジェクトの目的）
地域住民の財産というべき「検査」・「健診」の情報が保健センターに蓄積されていた
検査情報

健診情報

有効活用と高齢化・情報化社会への基盤づくり

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication43

加古川地域の事例③ （当初の課題）（１）関係機関とのコンセンサスの確立と継続性（２）システムの設計と開発（基幹病院との連携、データの標準化など）（３）継続的な費用、経費の負担（４）個人情報の保護について（同意、アクセス権限、ネットワークセキュリティなど）
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication44

加古川地域の事例④ （システム概要）
加古川総合
保健センター

加古川地域保健医療
情報センター

検査データ
健診データ

（検査・健診データ etc.）
主治医へのみＡ診療所

インターネットＶＰＮ
主治医へのみＢ診療所
診診連携

検査・健診データ
科別情報、投薬情報など
主治医以外の医師への情報
科別情報、投薬情報など

中核病院

検査データ

（検査・健診データ etc.）
主治医へのみ

Ｃ診療所
診診連携

主治医へのみ総合病院（科別診療）
病診連携

容量：1ＭＢ
内容：氏名や住所等の基本情報
病名や薬の情報
健診５年分・検査20回分
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication45

加古川地域の事例⑤ （導入効果）

参画医療機関数：118/198ヶ所
システムへの同意者：73,083名
カインドカード（ＩＣカード）所持者 ：45,202名（平成19年9月末現在）
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication46

加古川地域の事例⑥ （成功要因）

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication47

７．医療健康分野のＩＣＴ利活用に向けて

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

48

導入推進体制
健康長寿社会のための生涯健康情報基盤（ＥＨＲ）の実現に向けて、基本計画の策定とその推進スキームづくり●設立準備体制の立ち上げ●生涯健康情報基盤システム推進委員会（仮称）●運営方針検討ＷＧ（仮称）●システム検討ＷＧ（仮称）
県内のステークホルダー：各市町村、各地区医師会、国保連合会、保険者協議会、健診事業者（医療機関）、地域民間企業等とのコンセンサス創り（１）運営理念、方針、サービス内容、運営体制（２）個人情報保護対応の方針（３）システム基本仕様
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

49

導入マスタスケジュール
第２期

第１期
特定健診
対応計画
オンライン
レセ対応計画

第３期

システム改修特定健診・特定保健指導の推進

平成２４年度までの結果評価

システム改修

健診情報とレセプト情報の分析▼平成２３年４月
原則オンライン

生涯健康情報基盤 プロジェク

住民コンセンサス
ト立上げ
情報化方針（推進委員会）

運用
開始

生涯健康
情報基盤

体制・基本設計
情報化全体設計（運営方針検討WG、システム検討WG）

健診・レセプト情報
災害医療
診療情報
介護情報

健診・レセプト情報・災害医療のシステム構築・整備

評価・改善

診療情報
の構築・整備評価・改善

介護情報の構築・整備

評価
・改善

健診情報
レセプト情報
診療情報
介護情報

Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

50評価・改善生涯健康情報基盤システムを導入することによる効果
を定期的に定量的に評価し、毎年改善する。
途中経過を住民の方に定期的に広報する（１）独立した評価委員会の設置（２）評価指標の設定とモニタリング （例）
評
価・
改
善
の
手
順

① 分野ごとの利用者数② 自治体・健診施設・医療機関・介護施設における質的向上、および効率化③ 住民満足度（自己の健康管理、各機関で健康情報が引き継がれる点、生涯の健康情報が保存維持される点、など）（３）改善策の設定と実行、広報活動
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication51

［おわりに］Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication

52

ＡＰＰＬＩＣからのお知らせ
ＡＰＰＬＩＣでは、ホームページへの掲載を通じて各種情報発信を行っております。
ＡＰＰＬＩＣが発信する情報を是非ご活用ください。
http://www.applic.or.jp/＜平成１８、１９年度の主な成果物＞(どなたでもご覧いただけます。)■地域情報プラットフォーム基本説明書（Ｖ2.0）■地域情報プラットフォーム標準仕様（V1.0 V1.5）■防災アプリケーション基本提案書（第２版）■医療・健康・福祉アプリケーション基本提案書(第１版)■教育アプリケーション基本提案書(第１版)■ブロードバンド全国整備に向けた都道府県ロードマップ(Ver1.0)■ブロードバンド整備・利活用事例集(Ver1.0)■ブロードバンド整備マニュアル(Ver1.0)■地域公共ネットワーク構築モデル仕様(第1.0版)
Copyright（C) 2008, The Association for Promotion of Public Local Information and Communication53

災害時医療におけるＩＣＴ活用モデル
基本提案書

財団法人

全国地域情報化推進協会

アプリケーション委員会

2008 年 3 月
第 1.0 版

目

次

第１章 はじめに
１．１

本書の目的

・・・・・・ Ｐ ２

１．２

検討の背景

・・・・・・ Ｐ ３

１．３

検討の経緯と課題

・・・・・・ Ｐ ３

１．４

活動計画

・・・・・・ Ｐ ５

１．５

ＰＴの活動経過・・・・・・ Ｐ ６

第２章 災害時医療におけるＩＣＴ活用の必要性
２．１

人命救助

・・・・・・ Ｐ ８

２．２

安否確認

・・・・・・ Ｐ１０

２．３

医療機関

・・・・・・ Ｐ１０

２．４

被災後の健康管理

・・・・・・ Ｐ１１

２．５

被災地における情報管理

・・・・・・ Ｐ１１

２．６

広域連携における後方支援の必要性

・・・・・・ Ｐ１２

第３章 ＩＣＴ活用モデルの方向性
３．１

災害時におけるＥＨＲの活用・・・・・・ Ｐ１４

３．２

災害時医療における情報デバイスの活用

・・・・・・ Ｐ１６

第４章 ＢＣＰに基づいたＩＣＴ活用モデル
４．１

ＥＨＲ活用のモデル・・・・・・ Ｐ２４

４．２

具体化のために・・・・・・ Ｐ３２

４．３

ヒアリングの結果と今後の課題

・・・・・・ Ｐ３８

４．４

総論

・・・・・・ Ｐ３９

携帯電話活用のモデル

第５章 自治体導入への留意点
５．１ 自治体導入への目的について・・・・・・

Ｐ４３

５．２ 導入における課題点

・・・・・・

Ｐ４４

５．３ 災害と救急時・・・・・・

Ｐ４６

５．４ システムの普及啓発

・・・・・・

Ｐ４７

第６章 ＮＷセキュリティプロジェクト構成員・オブザーバー 一覧

1

Ｐ４８

第１章

はじめに

１．１

本書の目的

（財）全国地域情報化推進協会の事業内容として「自治体で共通利用が可能な公共アプリ
ケーション（防災、医療、教育等）の整備の促進」活動を行っている。この活動の一環として、「医療・健康・福祉ワーキング（以下、本ＷＧという）」では、自治体を中心にしたＩＣＴの活用による医療・健康・福祉分野の情報連携と活用を想定し、各自治体で利用可能なアプリケーションの検討と提案活動を進めている。
「ＮＷセキュリティプロジェクト（以下、本ＰＴという）」の活動は「ＥＨＲ（健康領域）
プロジェクト」が検討している「生涯健康情報基盤（以下、ＥＨＲという）（図１−１「ＥＨＲを中心にした情報の連携イメージ」を参照）」を自治体等で導入した場合を想定し、ＥＨＲの災害時医療での活用を昨年度より検討している。
本書では、自然災害や人災等による災害に対して、ＢＣＰ(Business Continuity Plan：
事業継続計画)にそって平常時から災害発生、回復期のフェーズを分類し、災害時医療に必要な情報とそれに関するセキュリティに関して、下記の点を留意し考察する。
・自治体で災害時医療に関するシステムを導入する際の手引き
・本ＷＧの他のＰＴ（特にＥＨＲ−ＰＴ）に対し、災害時医療で必要とする情報の提言
・防災ＷＧへ対し、災害時の情報を自治体内外で広域的な範囲で連携する必要性の提言
考察方法として、ネットワークや情報デバイス等のＩＣＴを活用した「災害時医療におけるＩＣＴ活用モデル」を想定し検討する。また、本書を自治体で災害時医療に関わる関係者等が活用する事を想定し、自治体等がシステムの導入時や災害時に円滑に利用するた
め平常時の災害に備えた研修や広報活動等も含めて考察する。
保険者

健診情報
レセプト情報健康推進アプリケーション(仮称)
統計情報

健診情報
医療・介護レセプト

医療・介護
健診機関

診療情報
(ｻﾏﾘｰ)

診療情報(ｻﾏﾘｰ)
レセプト情報・健診情報蓄積機能・健康情報提供機能
・統計データ作成機能（・介護予防支援機能） ＋α

関連機関
健診加工情報

医療情報
健診情報
介護情報

健診情報
運動実施結果情報

介護ｻｰﾋﾞｽｱﾌﾟﾘｹｰｼｮﾝ(仮称)

災害時医療支援ｱﾌﾟﾘｹｰｼｮﾝ(仮称)・介護サービス情報共有機能
・介護予防支援機能＋α・医療・健診・介護情報抽出機能＋α

図１−１「ＥＨＲを中心にした情報の連携イメージ」

2

住民

１．２

検討の背景

わが国は、少子高齢化という大きな課題を抱えているなかで、医療･健康･介護･福祉分野のサービス利用者の増加が見込まれている。このような時代背景のなか、近年、これらサービスを効果的かつ効率的に推進するためのＩＣＴの発展は政府の指導も有り目覚ましく、
電子カルテ等の施設内でのＩＣＴ活用だけでなく、遠隔医療や地域連携の形で実現、またレセプトオンライン請求、特定健診制度による電子化も進みつつある。
昨年度は「災害救急現場における医療支援システム」の実証実験を通して、災害時において平常時に活用している「住民の医療・健康・福祉情報」を活用するために情報へアクセスするコントロール権等の課題の検証、災害救急医療に携わる医療関係者等へのヒアリ
ングや有識者を招いての勉強会を実施し情報を収集し報告書を纏めた。
その中で、災害時医療の現場で重要な情報のひとつとして、被災者の過去の医療情報に対するニーズが非常にあること、災害発生から回復までのフェーズで必要とされる情報が微妙に異なることも判明した。
一方、災害や機器の故障に対応したＢＣＰの策定が義務付けられて来ており、厚生労働省
も「医療情報システムの安全管理に関するガイドライン第２版(平成１９年３月版)」において、医療情報システムもＢＣＰに含めることを求めている。
このことから、災害発生時から回復までの各フェーズにおける情報の種類を考察することが重要と認識した。

１．３

検討の経緯と課題（１）経緯
平成１８年度は「医療・健康・福祉アプリケーション基本提案書（第１版）」のな
かにおいて、「ＮＷセキュリティプロジェクト検討報告書（第１版）」を作成した。
ここでは「災害救急現場における医療支援システム」を想定し、公共ネットワークを活用した被災地内の医療・健康・福祉に対する救急支援アプリケーション、及び被災地内外における被災者情報ネットワークセキュリティのあり方に関する実証実験を新潟県三条市で行い、評価及び課題の抽出を行った。
具体的には災害発生時における活用可能なネットワークの検討及び医療情報へのア
クセスに関する考察を行い、実証実験結果とこれに伴うヒアリングによる評価を提示してある。そこでは、災害発生時に必要となる医療情報や当該医療情報の扱いとセキ
ュリティの問題に言及し、災害発生時から災害収束時における医療情報へのアクセス権限やアクセス制御等に対して、評価及び課題の抽出を行った。
これを受け、平成１９年度においては、並行する他の本ＷＧでのＰＴでの検討事項も配慮し「災害時におけるＩＣＴ活用モデル」の検討を行い、平成２０年度以降の取り組みに繋げることとした。

3

（２）課題平成１８年度に検討した際の課題は下記のとおりである。
①

考慮すべきフェーズ

医療システムが取り扱うフェーズを論理的に分けるならば、日常医療、救急医療、災害時医療ということになる。また、平成１８年の医療制度改革関連法により、平成
２０年度から医療保険者による４０歳以上被保険者の健診が義務化されることもあり、健診データの蓄積と医療への活用が志向されるようになり、これらも含めて医療シス
テムとの連携を考慮する必要がある。
②

考慮すべきネットワークの範囲

自治体等における地域内医療の高度化に関しては、ＥＨＲ活用、病診連携、地域内医療機関連携が検討すべき範囲である。しかし、今後は隣接自治体等との広域での連携医療についても考えて行く必要があり、地域間や広域連携も視野において検討を進めることが重要である。ただし、地域間や広域連携を考えるためには、現在それぞれ独自に運用されているネットワークの接続やシステムで使用している用語の統一等が問題になる。それぞれが異なる運用ポリシーに基いて運営されているため、ポリシーの調整とともに、異種ネットワーク間の接続調整やアドレスの衝突の調整等も技術的には必要となる。特に、広域の医療ネットワーク構築に関しては、誰が調整の最終決断をするのかという運用上の問題も発生する。
③

ネットワークに求められる要件

連携の範囲および伝送すべき医療情報の種類に応じて、必要とするネットワークの速度、ＱｏＳ、経路保障等によるセキュリティ対策について検討する必要がある。また地方においては、ブロードバンド過疎地も存在しており、それらも考慮したうえで、モデル的なネットワーク構成や機能要件を検討する必要がある。
④

システムレベルでの具体化とデータ交換方式の統一化

実際の次世代医療情報システムを考える上では、システム機能の具体化についても検討をする必要がある。ただし、個別のシステムはそれぞれの自治体に依存しているため、自治体間の接続に関しては特定のベンダの技術等に偏るのではなく、オープンな環境のもとで接続性を確保することが重要である。
・ 端末についてはインタフェースの要件を定め、アプリケーションについてはＡ
ＰＩ（Application Program Interface：アプリケーションがシステムの機能を利用するために使われるインタフェース）を定めることが必要である。
・ 医療データは医療機関での相互運用性が必要になり、用語等の標準化は必須である。
・ 災害時医療に必要なデータは限られたデータであり必要な共有情報を最低限統一することが望ましい。

4

・ 物理ネットワークは、状況に対する対応度に応じてモデル的なネットワーク構
成を示すことが重要だが、最終的にはＩＰネットワークにより接続する点のみを担保することが必要。
⑤

利用の見込まれる次世代技術と課題

次世代の医療情報システムは今後に向けて検討、整備していくべきものであり、ネットワーク技術およびセキュリティに関する最新の状況を勘案し、また最新の技術を活用して構築していく必要がある。
・ ＩＰネットワークを前提として考えた場合、新たなＩＰｖ４アドレスの配布が不可能になると言われており。広域連携を含む次世代医療情報システムとしてもＩＰｖ６の利用を前提とした検討が必要である。
・ セキュリティの観点から、必要とする相手のみと安全に通信が出来るという条件も重要であり、マルチレイヤー技術等により、同じ物理的ネットワークを共有していても、特定の許可された相手のみと通信できるような技術の採用を検討する必要もある。
・ 防災等の観点から考えると無線アドホックネットワークを利用できる基盤を構築し、災害時には早急に展開できるよう日頃から準備していくことも重要である。
⑥

運用に対する課題

システム的に取り扱える問題はなるべくシステム内で取り込み、医療連携上の阻害要因を低減し、それにより運用者の介在を少なくしセキュリティ上の脆弱性を減らすことが出来るが、人に関する部分は運用上の課題として残されることになる。
しかし、これらを災害時に急に運用していくことは難しいが、そのような災害が発生することを想定した平時での運用体制づくりを意識して訓練活動、或いは市民等への広報活動が重要である。
また、災害時医療システムの運用という観点からいうと、例えば平常時から災害時モードへの切り替えのような運用レベルの変更の条件、具体的なシステム的な実現方法について、明らかにしておく必要がある。

１．４

活動計画

（１）平成１９年度到達目標
下記の項目に対して検討し「災害時医療におけるＩＣＴ活用モデルの基本提案書（案）」を作成する。
①

前年度の検討課題の整理②

プロセスに基づく災害時医療に必要な情報項目の要件を整理③

具体的なシステム利用者と扱う情報の整理

5

・システムの利用者→ 被災者と支援者→ 支援者と後方支援者
・災害時医療に必要な情報

等→ 基本情報→ 医薬品情報④

等

災害時医療に必要な医療情報をＥＨＲ−ＰＴ（プロジェクト）への提言（２）最終目標（平成２０年度到達目標含む）①

平成２０年度の活動内容

・ 自治体向け基本提案書（最終版）の作成
・ 被災自治体内において避難住民の健康を維持するためのＥＨＲ情報の有効な扱
い方の検討
・ 負傷者情報を周辺自治体（後方支援病院）と迅速にやりとりするための有効施策の検討
・ 周辺自治体が住民情報（匿名情報）を活用して被災自治体を救済するための有効施策の検討②

生涯健康情報基盤構築に向けた実証実験システムの構築③

国（厚生労働省等）との意識共有化（制度上の課題の抽出、ならびに解決策の検討）④

自治体への普及啓発活動⑤ＥＨＲ構築に関するセキュリティ要件の検討（平成２０年、２１年度を目標）
・ＥＨＲのシステム基盤構築時のシステムの可用性（ネットワークのアベイラビリティも含む）
・広域連携に関してのセキュリティポリシーの統一

１．５

等

ＰＴの活動経過（１）本ＰＴ検討会の開催実績
回

開催日

第１回

７月１１日

検討テーマ
１．今年度の活動概要について（１回目）
２．今後のＮＷセキュリティＰＴの進め方について

第２回

７月２６日

１．今年度の活動概要について（２回目）

第３回

８月２９日

１．加古川市における健診データの利活用について
２．災害時医療におけるＩＣＴ活用モデル（案）について

第４回

９月２６日

１．災害時医療におけるＩＣＴ活用モデル（案）について

6

２．災害時におけるＩＣＴ活用モデル検討ワークシートについて①携帯電話の利用
第５回

１０月２４日

②昨年度の実証実験モデル

１．ＮＴＴドコモ様の事例紹介「災害時のＩＣＴ活用について(案)」２．災害時におけるICT活用モデル検討ワークシートについて①携帯電話の利用

第６回

１１月２１日

②昨年度の実証実験モデル

１．災害時におけるＩＣＴ活用モデル検討ワークシートについて①携帯電話の利用②昨年度の実証実験モデル

２．ヒアリングについて①ヒアリング内容②アリング先 等

３．報告書作成方法について
①項目立て

②作業分担

第７回

１２月５日

同上

第８回

１月９日

１．ヒアリングについてヒアリング状況等

等

２．報告書作成方法について
項目内容 等
第９回

１月２８日

同上

第１０回

２月１４日

基本提案書案（第０版）レビュー

第１１回

２月２５日

基本提案書案（第０版）レビュー（２）本ＰＴ検討会にて実施したヒアリング実績
ヒアリング先実施日

岩手医科大学

平成１９年１２月２０日

独立行政法人国立病院機構災害時医療センター

平成１９年１２月２５日

広島大学医学部

平成１９年１２月２６日

広島県

平成１９年１２月２６日

新潟県三条市
情報政策課 健康推進課

防災対策室

平成２０年

１月１５日

平成２０年

１月２５日

加古川市
総務部危機管理室
福祉部

高齢者・健康支援局健康課

7

第２章

災害時医療におけるＩＣＴ活用の必要性

２．１

人命救助

災害医療における諸活動の目的は人命救助に集約されることは当然である。特に災害を時系列でみると、発生直後においては負傷した被災者の救出が活動のすべてであるといえる。
平成７年 1 月１７日に発生した阪神淡路大震災では、地震による死者総数 6,434 人（消防庁）、このうち監察医及び日本法医学界派遣医師によって検案された遺体のうち、93.6％
が午前 5 時 46 分の地震発生から１４分後の午前 6 時まで、１７日中には 99.6％が死亡したと推定されている（「阪神・淡路大震災

神戸大学医学部記録誌」神戸大学医学部）。す

なわち、死亡者の９割以上が即死状態であったとされている。災害の種類によってこの比率は変化するであろうが、発生直後の救急活動を、より効率化し迅速化することは災害医療の恒常的課題といえる。
阪神淡路大震災の場合、死因のほとんどは家屋の倒壊や家具等の転倒による圧迫死だったとされている。しかしその死因をより詳細にみると、最も多い死因は「窒息死」54％であり「圧死」12％を上回っている（横浜市立大学

西村明儒助教授調査結果

神戸新聞

2004.4.21）。この結果をどう捉えるかについては複数の見解があるが、窒息死の場合は 30分以内の救出で助かった可能性を指摘する意見もある。
この段階では、どこに救出すべき人がいるかを知ることが最も優先される情報項目であり、個人の位置情報を確認できるデバイスが求められる。三条市へのヒアリングでは、発信は携帯電話、受信には災害時の通信インフラの強度や全域を見渡せることからＧＰＳ利用が適しているとの指摘があった。
ここで問題となるのは、「救出すべき人」とは誰を指すか、という点である。災害という言葉から負傷者のみをイメージしがちであるが、災害時要援護者への対応は災害医療の重要な課題といえる。平成１６年に発生した一連の風水害では、犠牲者の半数以上が高齢者であったことから、内閣府では高齢者等の災害時要援護者の避難支援などについて検討を進め、「災害時要援護者の避難支援ガイドライン（以下、ガイドライン）」（平成 17 年 3月）を取りまとめた。以来、防災基本計画に要援護者対策の必要性を明記することや避難所における支援等を中心に、ガイドラインの改訂が行われ市町村を中心とした取組の促進が図られている。
ガイドライン（平成 18 年 3 月版）では、「災害時要援護者」とは、必要な情報を迅速かつ的確に把握し、災害から自らを守るために安全な場所に避難するなどの災害時の一連の行動を取るのに支援を要する人々をいい、一般的に高齢者、障害者、外国人、乳幼児、妊婦などがあげられている。
風水害など予測可能な災害の場合は避難支援を行い、災害発生後には優先的に救出に向
かう、避難・救出後は福祉サービス等のケアを継続する、これら一連の支援活動の基礎となるのが災害時要援護者情報の収集と共有であり、具体的には名簿あるいは台帳の作成と支援関係者への配布である。この名簿を電子化して管理し、災害時には関係者が情報を閲覧できるシステムは、支援活動の上で非常に有用と思われ、ガイドラインにおいてもその8必要性が記述されている。
しかし、収集すべき情報は機微な個人情報であり、収集に非常な困難を伴っていることが加古川市へのヒアリングにおいて指摘された。ガイドラインにおいては平常時の情報収集・共有に以下の三つの方式があげられている。
①

関係機関共有方式

地方公共団体の個人情報保護条例において保有個人情報の目的外利用・第三者提供が可能とされている規定を活用して、要援護者本人から同意を得ずに、平常時から福祉関係部局等が保有する要援護者情報等を防災関係部局、自主防災組織、民生委員などの関係機関等の間で共有する方式。
②

手上げ方式

要援護者登録制度の創設について広報・周知した後、自ら要援護者名簿等への登録を希望したものの情報を収集する方式。
③

同意方式

防災関係部局、福祉関係部局、自主防災組織、福祉関係者等が要援護者本人に直接的に働きかけ、必要な情報を収集する方式。
（「災害時要援護者の避難支援ガイドライン」平成 18 年 3 月 より抜粋））
災害時の人命救助という目的は、①関係機関共有方式における「保有個人情報の目的外利用・第三者提供が可能とされている規定」に含まれると考えられるが、この方式を採る場合は個人情報保護審議会の審議等を経ることをガイドラインで示唆しており、やはり社会的にコンセンサスを得ることが必要となる。
さらに前述したＧＰＳ利用による位置把握などを構想する場合、災害時要援護者
はデバイス使用に制約がある場合があり、最も必要とする人が使えないということがないように配慮すべきであるという意見が、加古川市と三条市のヒアリングで共通して出された。
表２−１ 「災害の種類と支援」
災害種類
気象災害

地震・火山

予測可能性
風水害に代表される気象災害は、気象

支援
住民への周知、避難誘導

観測によってある程度予知が可能
地震・火山噴火などは予測研究が進ん

住民への周知はメディアにでいるが、事前の避難・準備は現時点

よる地震情報アナウンスなでは困難。津波は距離によって予測がどに留まる。

可能生物
人災

新型の病原菌などは発生源から遠い住民への周知、対策が可能場合はある程度予測が可能
予測不能

発生後の対応

9

２．２

安否確認

三条市のヒアリングでは、災害発生後は自治体に対し被災者の家族等から安否確認の問合せが多数あることが、平成１６年の水害時の経験から指摘された。避難所では入所時の紙記入により名簿を作成し、自治体はこの避難者名簿に拠って回答することが一般的である。
名簿を電子化すなわちデータベース化しネットワークを介することで、一元管理と各部署での情報共有が可能となり、安否確認の即時性が高まることが期待できる。こうしたデー
タベースは個人情報の何を入力すべきか、考えられる情報項目を表２−２にまとめたが、特に受療を含む健康情報を範疇に含む場合は個人情報保護の観点からの議論を尽くさねばならない。したがって安否確認に限定したデータベースとした場合の構築や運用のあり方
は、防災ＷＧでの議論として深められることを提案する。またデータベース化が成った場
合もホ−ムページ等での掲示など誰もが閲覧できる方法は採りがたいという指摘が三条市
ヒアリングから得られた。【表２−２】
個人間の安否確認へのＩＣＴ利用については「災害伝言ダイヤル」など、民間の取組みが既に始まっており、実際の活用例からみて確実に認知が拡がっていると思われる。
表２−２ 「安否確認に必要な情報項目」
情報項目

必要度と情報の属性

名前

必須。

住所

必須。名前との照合によってほぼ個人特定が可能となる。

生年月日

必要度は低いが、避難所ごとの乳児や高齢者数は、物資搬送におけるデータとなる。

性別

必要度は低い。

健康情報

負傷・疾病の有無や重篤度、あるいはアレルギー、服薬情報など。より詳細な安否情報としての位置付けも可能であるが、医療でのＩＣＴ活用として論じられるべき情報項目である。

医療措置

同上

医療機関等に搬送の有無

同上

２．３

医療機関

被災地の医療機関には多数の患者が集中するため、医療措置の優先順位を適切に判断することが、より多くの人命を救うことに直結する。救出現場で行なわれるトリアージはその最初期の段階だが、医療機関に搬送された患者についても必要な個人情報が確認できれば、優先度判断の適切さと時間短縮に寄与するものと考えられる。また医療措置そのものにも効率化が図れると期待できる。特に緊急に知ることができれば診療に役立つ情報項目としては、常用薬情報、アレルギー情報、慢性疾患情報が昨年のヒアリングにおいて医師から10あげられている。
これらは機微な個人情報であり、平常時には本人の同意によって入手できる情報であるが、生命の危険を伴う災害時には平常時と違う情報開示の運用が求められる。また情報を参照
するに先立っては本人同定の手順が必要となる。
そして後方支援病院との連携において、情報を簡易に入力し伝送することが可能となれば、医療措置の質的向上と時間短縮に役立つと想定される。（本書項番２.６参照）

２．４

被災後の健康管理

復旧フェーズにおける災害医療を考えると、避難所や仮設住宅での感冒流行やストレスによる体調悪化などは、二次災害といえるものであり、被災者の健康管理が大きな課題である。特に災害時要援護者は被災後の生活・健康管理においても援護が必要とされることが想定される。ガイドラインにおいても、避難所において要援護者用窓口の設置や福祉避難所の設置を促している。
また、三条市ヒアリングにおいては被災後数年に渡って看護師や地域住民（ボランティア）による被災者世帯訪問聴取が行なわれていることが報告された。被災者が自宅に戻ってからも健康管理の継続が求められる。一般的に被災後の聴取記録は紙ベースで取られるが、ヒアリングからはその活用は地域担当保健師など行政においても限られた担当者の努力に待つところが大きいという状況が伺われた。
災害時にはそれら担当者の不測の事態や、負担が増大することが想定される。したがって被災後の健康記録をデータベース化し情報を共有することで担当者個人の知識経験に頼る割合を低くし、負担を軽減する必要性は大きいと思われる。
さらにデータは継続性・連続性が高いほど、健康管理の質の向上につながる。災害発生
以降の健康記録を被災者個人について経過的に一覧できることが、医師の診療や保健師の健康指導にとって貴重な基盤となることが期待できる。
また慢性疾患（透析患者、心臓病、糖尿病など）に対しては被災直後から継続的な医療措置が必須であり、２−１で述べた災害時要援護者と同様の平常時からの備えが必要となる。慢性疾患者の団体等との協力関係を築いておくことが望ましい。

２．５

被災地における情報管理

災害時には情報の精度と速度が平常時以上に求められるが、一方で情報の輻輳・錯綜が生じやすい状況となる。情報管理一般においては防災ＷＧにおいて議論を深められるべき事項であるが、災害医療における情報管理に限定する形で考察する。
情報の管理のあり方は、表２−５のように復旧へ向かうフェーズによって変化すると考えられる。【表２−５】

11

表２−５

「情報管理状態の変化」

フェーズ
発生予測

情報管理状態風水害等、災害が事前に予測可能な場合は、自治体が整理した情報を住民に周知し、災害時要援護者を優先した避難誘導を混乱なく行なうため一元管理された情報を活用する。

発生直後

救出活動の速度を最優先するため、情報は精度よりも速度を重視
し、一極においてすべての情報を時系列で集積する。情報の修正を随時行なっていくため情報発信の時系列を明示する。この手法は昨年度の兵庫県災害医療センターへのヒアリングにおいて「ＪＲ福知山線脱線事故」の事例から指摘された点である。

医療活動開始医療機関等へ必要な被災者情報を開示する。昨年の実験に伴う筑波メディカルセンター病院、兵庫県災害医療センターへのヒアリング
では、常用薬情報・アレルギー情報等のほか搬送患者の表情等が医療措置準備に役立つとの指摘があった。

復旧時

後方搬送等に際し開示した個人情報の閉鎖。災害時医療（拠点病院）
から平常時医療（かかりつけ医）への移行に際し、退院時サマリーの作成・提供。いつどんな状態で搬送され、どういう措置をしたかの記録がその後の診療に役立つ。

２．６

広域連携における後方支援の必要性

被災地に向けては広域からの支援が不可欠であり、これを迅速かつ効率的に実施するための法整備を含めた検討やＩＣＴ利活用の技術的議論は、国あるいは都道府県レベルでの議論を進めるべき課題である。またＡＰＰＬＩＣにおいては防災ＷＧにおいて総合的な防災対策の一項目として検討されたい。
ここでは災害医療における後方支援の必要性を検討するが、医療従事者や医療物資等の被災地搬送などに関わる業務については、上記の防災対策に含まれるものとし、主に後方支援病院等の医療措置における必要性に限定して考察する。
昨年度の本ＰＴでは三条市（新潟県）
・筑波メディカルセンター病院（茨城県つくば市）
・
兵庫県災害医療センター（兵庫県神戸市）を結んで行なった実験において、主に平常時に格納した健康情報と災害時に生成した情報をオンラインかつリアルタイムで他自治体や後方支援病院等で見られるように開示するシステムを想定し、必要な情報項目や開示における課題の抽出に取り組んだ。その結果得られた、必要な情報項目は表２−６の様にまとめ
られる。

12

表２−６「災害時医療における後方支援に必要な情報項目」
情報活用の目的
投薬に必須な情報
医療措置に役立つ情報

情報項目
常用薬情報、アレルギー情報、慢性疾患情報
負傷疾病の種類と重症度、被災者画像、災害カルテ、医療データ、平常時

受入準備に必要な情報

被災地俯瞰情報

また被災地側からは搬送可能な病院の情報へのニーズが高い。その場合は下記の様な項目がヒアリングにおいてあげられた。
・ 医療機関の位置：最短距離の受入れ可能な医療機関
・ 医療機関の状況：災害によるダメージ、受入れの数的可否
・ 医療機関へのアクセス：周辺の道路状況（交通不能など）

13

第３章

ＩＣＴ活用モデルの方向性

３．１

災害時におけるＥＨＲの活用（１）ＥＨＲとは
ＥＨＲで取り扱う個人の健康情報は、①健診・保健指導情報 ②レセプト情報（診療報酬請求明細書） ③診療情報（要約情報） ④介護・福祉情報などである。平常時においては、個人を特定し個に応じた保健医療福祉サービスの提供に寄与する情報環境、そして匿名化された情報でサンプル規模ではなく全数で保健医療福祉サービスの状況が分析可能な情報環境、この２つの側面での利活用が想定されている。
本節では、ＥＨＲを災害時医療において利活用する方向性と要件を検討する。

（２）災害時に活用できるＥＨＲ
ＢＣＰとは「事業継続計画」であり、不測の事態が発生したときにも組織本来の目的を達成するための事前計画を言う。
医療機関であれば災害(地震、台風など)・ユーティリティの不具合(停電など)、機器の故障等へのＢＣＰ(各機関により名称は様々)は策定されているので、厚生労働省発行の「医療情報システムの安全管理に関するガイドライン第２版」において、医療情報シ
ステムもＢＣＰに含めることを求めている。平常時機能からの縮退・代替手段の開設やアクセス手段の緩和等(一般的にはブレークグラスと呼ばれる)である。
上記の「ガイドライン」は、各医療機関向けに災害時の医療情報システムのＢＣＰ策定を求めている。本書におけるＥＨＲで考えるべきＢＣＰは、災害時の地域医療体制継続であり、個別機関の医療情報システムを超える範囲を対象にしている。改めて繰り返
すまでも無く、災害時の医療サービス提供には平常時とは異なる体制を必要とすることである。
すなわち、地域としての自治体の観点からの平常時レベルの医療サービス提供体制の維持・回復のみならず、災害時特有の事情による特別体制を設けることである。
患者の来院手段途絶や医療施設の破損による利用設備の制約、医療関係者の被災のよる人的制約などが考えられ、平常時には開設しない医療施設(屋外設置、臨時施設開設)
でのサービス提供が求められる。更には、災害時に発生する特有な情報(トリアージなど)、
医療サービス提供箇所や安否問合せ、後方支援病院・救助支援者への情報提供もある。
これらの点を考慮に入れた「災害時に活用できるＥＨＲ」構築を行う必要がある。

（３）平常時とのデータ包含関係
平常時に用いられるＥＨＲデータと災害時に必要とされるデータは同等ではない。
昨年度の調査でもあるとおり、災害時に必要とされるデータとしては、本人確認手段が第一であり、かかりつけ医、アレルギー、投薬、慢性疾患、既往歴等が必要とされる。災害時用ＥＨＲとしてのデータは各自治体でＥＨＲ構築時に考慮する事項であるが、特定健診やレセプト情報からだけでは不十分の内容もありうる。

14

逆の側面から見ると、災害時医療においては被災者と面識の無い支援者による医療が行われる点から、本人が開示を制限したい情報を災害時用ＥＨＲデータに掲載することは控える必要がある。したがって、災害時に活用されるＥＨＲデータはＥＨＲデータ全体のサブセットである。
ここでの前提として、入院患者のデータ確保は医療機関のＢＣＰとしての範囲で考え、ＥＨＲとしては除外している。

（４）ＥＨＲが緊急時にも使えることへの配慮① ブレークグラス機能の実装
災害時におけるＥＨＲデータへのアクセス者は、ＤＭＡＴのＩＤ利用での認証が考えられる。しかし、臨時の救援者や後方支援病院内の従事者など、ＤＭＡＴ登録者だ
けではないことが充分ありえることから、平常時のアクセス制限のままでは不合理な事態が発生しうる。このための、アクセス制限の緩和がブレークグラスと呼ばれる機能である。緊急時にガラスを割って鍵を取り出す行為の類似性から名付けられている。
ブレークグラスにおいての機能は各ＥＨＲで考慮すべきことであるが、一般的にはブレークグラス状態にあることの周知方法、アクセスログの可否・手法、正常復帰後のデータ整合性などは考えておかねばならないとされている。
② 災害時用ＥＨＲデータの冗長化
災害時の利用を想定するとＥＨＲのロバスト性は必要であるが、ＥＨＲだけでなく通信環境などにも依存し１００％のロバスト性は不可能である。そのためにはデータの冗長性を考えておくことが必要である。紙でも保存することは最終手段であり、それ以前にＩＣＴを活用した手法、例えば本人携帯電話に常時送付、近隣自治体間での相互バックアップ、民間データセンターへの保管委託(この場合は発災時に限定して利用できる仕組み)等が考えられる。しかし、あまり複雑な仕組みだと、最新状態への維持が困難になる。
＊ロバスト性：外乱や設計誤差などの不確定な変動に対して，システム特性が現状を維持できること③ データ入力機能の有無
災害時という状況を考えると、救助関係者からの緊急医療措置内容・負傷者データ・
トリアージ登録、搬送先の後方支援病院へのデータ転送、などの関係者間の共有デー
タとしてのＥＨＲへのニーズがありうる。しかし、本来のＥＨＲにこのような未確定の経過データを保持する目的が含まれているか否かによって考えるべき機能である。
不用意に機能を含ませると、管理できないデータが残ってしまう可能性がある。
また、ＥＨＲが第１章に述べた様に、レセプト情報や健診情報からのサマリーとす
ると、保険者にレセプトが行かない診療データはＥＨＲに反映されないことになる。
災害時の診療データがどのような流れでＥＨＲに蓄積されるのか、あるいはされないのか、「生涯健康情報基盤(ＥＨＲ)」としての目的に適うのかを事前に把握しておく15

必要がある。

（５）ＥＨＲを使うにあたっては① 情報主体者(住民)への事前周知と了解
災害時で使うための「ＥＨＲデータの存在、データ収集活動の存在」と同時に、前述した「最悪、この範囲のデータ以上には使えない」、「主治医以外が利用する」ことの周知が求められる。
即ち、災害時には情報アクセス制限が緩和され救助支援者に開示される可能性が高
いため、余りにも機微な個人情報は災害時用ＥＨＲデータとしては持ち得ないことの説明が必要である。
即ち、宗教・思想・信条などの事情、家族内の事情、遺伝子情報、等は医療行為において考慮されないリスクが有り得る。かかりつけ医と比べて医療サービスに限界がある。
② 近隣自治体、後方支援病院への依頼・人的バックアップ
多くの支援者が関与することになるため、データ表現・データアクセス手段の標準化が必要である。各標準化組織による標準化内容を積極的に取り込むＥＨＲ構築が重要である。
③ 運用ポリシーの策定
システムの管理運営には、そのポリシー(基本方針、管理運営組織・手段など)の作成が重要である。ＥＨＲとしては当然作成されている文書であるが、ＢＣＰの一環として「災害時のポリシー」も含めて作成されることが強く望まれる。

（６）現在政府で進めている「電子私書箱機能（仮称）」の利用
個人が利用できる電子私書箱として、対象情報には特定健診結果、レセプト情報、診療情報が例示されている。将来的には整合性を考える必要がある。

３．２

災害時医療における情報デバイスの活用（１）災害時医療におけるＩＣＴ活用として情報デバイスを用いる意味
災害時医療という様々な意味で混乱した現場において、ＩＣＴを活用した情報の取り扱いを行うためには、ネットワークや情報伝達手段の確保、災害時用の情報運用ルールの策定、システム的なサポートの仕組みの開発、災害の各フェーズに対応したケ
ア、医療以外の場面との多様な連携等が必要であるが、その多くは、本ＰＴの昨年度までの検討や、各省庁での委員会・研究会等での検討、ベンダによるシステム／アプ
リケーション開発・提供により、一定の解決の方向性が見えつつある。
一方、阪神・淡路大震災から平成１９年新潟県中越沖地震までの地震災害での被災経験や数多くの豪雨・水害等の経験、ＪＲ福知山線脱線事故のような不慮の大事故に16

おける経験から、災害等で混乱した医療現場において、いまだ何が足りないのかという点も明らかになりつつある。
本基本提案書では、災害時医療におけるＩＣＴ活用として、ＥＨＲの活用やＢＣＰに基づくモデル検討を実施しているが、本節においては、それらをサポートするツールとして、情報デバイスの有用性や要件、課題等について検討を行う。
①

個人を特定する役割

災害時医療に対してＥＨＲの活用を考えたとき、被災者本人とＥＨＲの持ち主が同一人物であるかという本人性の特定が非常に重要となる。仮にＥＨＲが利用可能な状態であっても、誰のＥＨＲ情報を引き出すべきなのかが分からなければ、医療において活用することはできない。また、間違って別の人のＥＨＲ情報と取り違えてしまった場合には、重大な事態を招きかねない。これは被災者本人が意識混濁・意識不明等
により意思疎通ができない場合だけでなく、移動・搬送中の本人取り違え等の場合にもありうることである。
このような問題の発生を防ぐため、本人の特定を確実なものとする方策の１つとして、情報デバイスの活用が考えられる。本人に紐付けられた情報デバイスがあれば、それを本人確認のためのキーとし、確実に本人のＥＨＲ情報を引き出すことが可能である。ただし、その情報デバイスが確実に持ち主のものであるかという別の問題もあり、その点は課題として整理する必要がある（３．２（２）②において詳述）。
②

ＥＨＲ情報を保持する役割

災害の種類によっては、特に発災直後などに通信網が途絶し、ＥＨＲにアクセスできない場合があると考えられる。特に災害現場に設置された救護所などでは、臨時の通信回線を新たに引く必要が生じたり、その場合でも電話が優先され、高速通信回線の設置には時間がかかったりする可能性も高い。また、被災者を運ぶ救急車の中など、いち早い応急措置を必要とするにも関わらず、ネットワークへのアクセスは限定されたものとなる。従って、災害時医療において、ＥＨＲの活用をより有効なものとする
ためには、最低限のＥＨＲ情報を被災者本人が保持していることが望ましいといえる。
①で述べた情報デバイスが本人特定のために利用されるものであるならば、それは常に携行されることになるか、もしくは拠点・拠点において、本人に紐づくなどの機能を持つことが期待される。従って、最低限のＥＨＲ情報を情報デバイスに保持しておくことにより、災害時医療の現場において、ＥＨＲの活用性が高まるものと期待される。
一方、ＥＨＲ情報を情報デバイスに蓄えておくことになると、その情報の鮮度管理という新たな課題が生じる。ＥＨＲのシステム本体に蓄えられた情報であれば、履歴も含めて最新の情報が利用可能であるが、情報デバイスの場合、メモリ容量等の関係
から全てのデータを蓄えられない可能性も高く、仮にメモリ容量の問題が解決して全ての情報を蓄積可能だとしても、機微情報を含む個人情報の取り扱いという観点から、その全てを日常的に持ち歩くことが適切なのかという問題もある。従って、情報デバ
イスにＥＨＲ情報を保持するのであれば、ある程度絞り込まれた情報を、しかも最新17

の情報のスナップショットとして更新、保持していく仕組みが必要である。
さらに、ネットワークにつながっていない時に、情報デバイスに保持されたＥＨＲ
情報を利用して医療行為を行い、ＥＨＲ情報に更新が生じた場合には、更新されたＥ
ＨＲ情報の原本をどこにどう保持するのか、ネットワーク接続後にどのようにデータベース上の原本と統合するのか、原本性の観点からの課題検討も必要と考えられる。
③

その他災害時医療情報を伝達する役割

災害時にＥＨＲを有効に活用するためには、本人確認、ＥＨＲへの接続性の確保、接続不能の場合の最低限のＥＨＲ情報の保持が必要であるが、これらの機能をサポー
ト可能な情報デバイスであれば、さらに拡張的な役割を持たせることも可能と考えられる。
例えば、接続可能な回線がある程度の帯域を持つものであれば、医療拠点への移動
中に、バイタル情報等を本人性の確認情報と紐付けた上で事前に送付するツールとして利用することも考えられる。あるいは、診察結果や治療に関わる情報、トリアージに関する情報などを蓄えておく媒体として利用することも考えられる。トリアージは患者の状態を一目で見分ける必要があるため、色で区別する等の視認性が要求されるので、患者自身が所有する情報デバイスを用いるのは難しいが、災害医療用にあらか
じめ用意しておくトリアージタグを電子タグ付きのものとし、情報を蓄える機能も同時に持たせる等の検討はありえると考えられる。

（２）情報デバイスを活用するにあたっての注意点と課題
ここでは、災害時医療において情報デバイスを活用する際に考慮すべき注意点や課題について取りまとめる。
①

考えられる情報デバイスの例

まず具体的に考えうる情報デバイスであるが、日常的に、あるいは医療を受ける際に本人が持ち歩くという点を前提に考えると、以下のようなデバイスがその候補として挙げられる。
【表３−２−１】
表３−２−１「災害時医療において利用される情報デバイスの候補」
デバイス種類
電子保険証

利用上の利点

利用上の欠点や留意点· 公 的な本人確認書類とな· ネット ワーク対応した読る

み取り デバイスが別途必
要· 個人単位での発行が必要· ＥＨＲ 用のデータ領域が必要

社会保障カード· 公 的な本人確認書類となる· ネット ワーク対応した読
み取り デバイスが別途必

18

· 個 人単位での発行が 期待

要· ＥＨＲ 用のデータ領域がされる

必要
ＩＣ運転免許書· 公 的な本人確認書類とな· ネット ワーク対応した読る

み取り デバイスが別途必· 個人単位で発行される

要· 医療用 途でないため医療用に使うには議論が必要· ＥＨＲ 用のデータ領域が
必要

電子診察券

· 発 行元においてはカ ルテ· ネット ワーク対応した読情報をすぐに引き出せる

み取り デバイスが別途必· 最 低限の診療情報を 格納

要· 特定の 病院やグループでできるものもある· 個人単位で発行されるしか使えない· そのま までは公的な本人確認書類とならない

携帯電話· 多 くの個人が日常的 に持· 災害時 にはネットワーク

ち歩いているが切れる可能性がある· そ れ自身が入力およ び表· 専用ア プリ等の導入が必示機能を備えている要· そ れ自身がネットワ ーク· 複数の 方式があり常に互接続機能を備えている

換性の検証が必要（新機種への対応に時間が掛かる）

本人認証のための特別 · 専 用の情報デバイスとし· 新たな開発が必要なデバイス· 必ずし も個人が日常的にて 必要な機能を全て 備えることが出来る

持ち歩くとは限らない

それぞれ、利点、欠点、あるいは留意点はあるが、情報デバイスを活用する上で、留意しておくべき点を分類すると以下のようなポイントになると思われる。【表３−２−２】
表３−２−２「情報デバイス活用上の留意点」
項目分類
本人確認性

留意点
· 公的な本人確認書類であるか· 本人確認の有効範囲はどの範囲か· 個人単位で所持しているか

ＥＨＲへの接続性· 単体でネットワークに接続可能か· 災害時のネットワークの接続性はどの程度確保できるか19

· ネットワーク接続時の回線容量はどの程度か· 電子カルテと直接結びつくようなコードを持っているか
単体でのデータ保持その他· 最低限の診療情報やＥＨＲ情報を単体で保持できるか· 単体で情報の入出力や確認が可能か· それ自身が電源を持ち単独で動作可能か· 日常的に持ち歩いているか· 災害時に容易に持ち出し可能か· 既に存在しており今すぐ使えるか、今後開発する場合には必要な機能を盛り込めるか· 共通な基盤の上で共通の機能を利用可能か· システムと接続される場合のインタフェースが統一されているか（電気的インタフェース、論理的インタフェー
ス）②

情報デバイス活用の注意点と課題

情報デバイスを活用する上で考えられる注意点のうち、代表的な幾つかの課題について以下に考察を行う。
ア）持ち主と本人の紐付け方法
３．２（１）①で触れたように、情報デバイスを用いて本人確認を行う場合には、
その情報デバイスが本当に本人のものなのかという点が重要なポイントとなる。単純にそれを所持しているだけでは、本人のものであるとは完全に言い切れず、また本人でない場合の医療的影響を考えると、持ち主と本人が確実に一致していることを担保する手段について考慮する必要がある。
まず、その情報デバイスが公的確認書類であれば、その発行プロセスにおいて一定レベル以上の本人確認が実施されており、本人確認の信用度は高いといえる。また、ＩＣ免許証のように写真付きであれば、より本人証明能力も高く、たまたま人のものを拾って持っている等の状況であっても、取り違えの可能性は少なくなる。最新のＩ
Ｃ旅券のように本人の指紋情報等の生体情報を取り込んでいれば、確実な本人確認が可能となるが、生態情報を取り込んでおくこと自体への法的、運用的、あるいは社会通念上の問題、生体情報を緊急時に読み出し本人のものと比較する方法論等については議論が必要である。
イ）セキュリティの確保
情報デバイスを有効に活用するためには、いざという時にきちんと使えるという点が重要であり、本人が日常的に所持しているか、緊急時にすぐに持ち出せる必要がある。そのような情報デバイスが本人確認のための機能も併せ持つという点を考えると、デバイスとしてのセキュリティへの配慮は非常に重要である。
情報デバイスのセキュリティとして考慮すべき点を列挙すると、20

・ 内部に保持している情報のセキュリティ（暗号化）
・ 内部に保持する情報エリアのセキュリティ（専用データ領域の確保）
・ 情報を取り出して利用する際のセキュリティ（本人認証）
・ ＥＨＲ情報との連携の際のセキュリティ（ネットワーク暗号化等の安全確保）
・ 紛失や盗難時のセキュリティ（当該デバイスの無効化）等があげられる。情報デバイスとして何を利用するかにより、その実現方式も異なるので、それぞれのデバイスの特質や利用可能機能等も考慮した上で、詳細な検討が必要である。
ウ）通信装置との連携方法
ＥＨＲ情報を利用するためには、ネットワーク等を経由してＥＨＲへアクセスすることが可能である必要がある。情報デバイスを本人認証等に利用することを考えると、
情報デバイスを何らかの形でネットワークへ接続し、ＥＨＲとの連携を実現する必要がある。例えば携帯電話のようなデバイスであれば、それ自身がインターネットへの接続が可能であり、可用性は高いと言える。一方で、利用可能なセキュリティ技術（認証方式、証明書種類、暗号化方式等）は限られており、また回線速度に関しても、最新の高速携帯でも下り方向 3.6Ｍbps 前後、上り方向 384Ｋbps 前後（ただし公称値であり、実効値はより低い）であり、画像等容量の大きな情報のやりとりには十分とはいえない。
一方、電子保険証等のＩＣカード系のものは、カードリーダとセットになったネッ
トワーク接続装置が別途必要となる。ただし、高速回線を前提としたり、暗号化等のセキュリティ技術も要求に沿ったものを導入したりすることが可能であり、それぞれ、長所と短所を持つのが実情である。したがって、それぞれの長所を組み合わせ、より良い運用方法を検討する必要がある。
エ）最低限のＥＨＲ情報の保存
災害時、特にその初期においては、ネットワークが切断される等によりＥＨＲへの接続性が確保できない可能性が高くなる。また、電話や携帯等の無人局において電力供給が滞り一時的にバッテリー運用に切り替わったとしても、バッテリー切れにより発災後しばらくしてから回線が切れるようなケースもありえる。一般論として災害へ対する耐性の強弱の違いはあるが、固定網、移動網とも、回線が切断される可能性が存在する点は一緒である。
回線が切れているときはＥＨＲへのアクセスは出来なくなるため、それを利用しようと思うなら、情報デバイスに最低限のＥＨＲ情報を蓄えておき、それを利用できるようにする等の仕組みについて、あらかじめ整えておく必要がある。情報デバイスはその種類によって、蓄えられるメモリ容量に差があるため、あらかじめ最低限必要とされるＥＨＲ情報を定めておき、そのメモリ容量の範囲で確実に保存可能であるよう調整が必要となる。また、情報デバイスの多くは、もともと他の目的に作られたものを流用する形で検討することとなるので、ＥＨＲ用の領域を確保するための方策についての調整も必要である。

21

また、なるべく最新のＥＨＲ情報を保存しておくため、ＥＨＲへ接続された際の情報デバイスへの自動情報更新や、ネットワーク非接続時に情報デバイス上で更新された情報をＥＨＲ原本と整合調整するための原本性の確保方法等、検討すべき課題は多い。
オ）情報デバイス内の情報を取り出すための標準的なプトロコル
情報デバイスを本人認証に用いる場合、情報デバイスに蓄えられたＥＨＲ情報を利用する場合、いずれにおいても、情報デバイス内に保存された情報を取り出し、システム的な枠組みの中で利用できる形にする必要がある。
この情報の取り出しに関しては、セキュリティ上の考慮も必要とされる。また、災害時医療においてＥＨＲ情報を利用するアプリケーションは、それぞれの自治体の事情を踏まえ、現場の状況に応じて開発されるものと思われるので、様々な情報デバイ
スが利用できる可能性や広域連携を必要とする可能性を考慮すると、情報デバイスから情報を取り出すためのインタフェースやプロトコルは、何らかの形で統一が必要だと思われる。検討すべき要素を以下にあげる。
・ 物理的接続インタフェース（接触、非接触、ネットワーク接続）
・ 暗号化方式（利用暗号種類、鍵交換方式）
・ 必要情報エリアへのアクセス方式
・ 標準データ交換プロトコル
・ 標準ＡＰＩ・ 標準ミドルウェアカ）情報デバイスに関するブレークグラスの概念の整理
本検討の中では、ＢＣＰ発動プロセスにおいて、ＥＨＲを含む医療情報等へのアクセス権限を拡張する所謂ブレークグラスの概念を取り入れているが、情報デバイスの活用にあたってもこの概念への考慮が必要である。
例えば、意識不明等により本人の意思が確認できない状態のとき、本人以外の者が情報デバイスを用いて認証を通過し、ＥＨＲへアクセスすることを可能にする仕組みが必要である。災害時医療の対象者に関しては、大怪我等を負っている可能性も考えられるので、情報デバイスに生体認証を組み合せている場合には、その解除方法をあらかじめ考えておく必要があるかもしれない。
第４章において災害モードへ移行後の情報へのアクセス権限を拡大するための閲覧
キーについて触れているが、同じ閲覧キーが情報デバイスにそのまま利用できるかは、
情報デバイスの機器リソースにもよるので、よくよく設計検討が必要である。携帯電話の場合には、日本国内においてはＪＡＶＡやＢＲＥＷ等の複数のアプリケーション
実装方式が存在し、またセキュリティ機能のアドオンも難しいので、ブレークグラスの概念を取り入れた共通のセキュリティ基盤を今後の携帯に載せていくための調整を実施するか、携帯電話以外のより自由度の高いデバイス基盤の利用を図る必要があるだろう。
また、ブレークグラスの実現そのものに関しても、よくよくセキュリティ的に制御22

された状態でのアクセス権限の緩和を図る必要がある。一般的な情報管理という意味
で、通常期においては、不用意な情報漏えいの起きない様、セキュリティを確保し、仮に起きてもその状況をトレースして有効な対策を取れる様にセキュリティ・レベル
を確保することが要求されるが、災害等により混乱している状況で、アクセス権限を拡大した場合には、状況確認が不可能な状態で情報拡散が起きてしまうかもしれない。
一度漏洩した情報は独り歩きしていき、ＢＣＰを終了し、平常時モードへ移行、閲覧
キーを無効化しても、回収することは不可能であり、そうならないための、何らかの工夫が必要である。医療を最優先で実施しなければならない現場において、煩雑な手続きをなるべく少なくしなければならないという条件はあるが、・ あらかじめ登録してある者にしかアクセス権限を拡大しない
・ 登録者のキーと閲覧キー、情報デバイスのキーが揃わないとＥＨＲにアクセス出来ない
・ 取り出されたＥＨＲには登録者のキーが埋め込まれる（トレースを可能とす
る）等の方策について、詳細に検討していく必要があるだろう。

23

第４章

ＢＣＰに基づいたＩＣＴ活用モデル

災害医療においてＩＣＴを活用する必要性と、活用を構想するにあたっての方向性を前章までで検討してきた。その中で情報項目と活用の流れについても触れてきたが、本章ではＢＣＰに基づいたフェーズ区分に当てはめることによって整理し、災害医療におけるＩ
ＣＴ活用モデルを提示する。

４．１

ＥＨＲ活用のモデル

昨年度、本ＰＴにおいては実験を中心に、災害医療におけるＩＣＴ利活用のあり方、な
かでもネットワークによる関連機関間の被災者情報の管理・伝送とその運用について焦点をあて考察した。本項ではその成果を踏まえ、ＥＨＲ‑ＰＴにおける検討に対し、その利活用シーンの一つとして災害医療での活用を提言するためのモデル提示を行なう。

（１）ＥＨＲの災害時利活用に対する前提事項
１章で述べたＥＨＲで取り扱う情報は機微な個人情報であり、情報としてデータ管理し利用するにあたっては本人の同意を前提とするものである。当然、同意を得ずしてのデータ参照や他機関への開示は平常時では禁止さるべきものである。しかし、災害時においては本人の状態（意識を失った場合など）や生命の救出に際し、本人の同意を得ることができない場合が想定される。
この同意なしに情報開示する場合のアクセスコントロール運用とセキュリティ担保が災害医療への利活用において議論の中心となる。
①

データのバックアップ
ＥＨＲに格納された情報のコピーをバックアップ用として維持する手順を確立

し可用性を高める。
②

情報開示のアクセスコントロール（平常時と災害時）
平常時は登録住民、登録医師、保健師などがＩＤとパスワード、ＩＣカード、あるいは生体認証等の本人識別手段によってシステムにログインし個人データを参照する。そこには必ず本人の同意が前提としてある。しかし災害時には本人同意が得られないままに、生命保護のため個人情報を参照する必要が生じる。あるいは後方支援病院への情報開示・伝送は「個人情報の目的外の利用」にあたる可能性もある。
この点について「医療情報システムの安全管理に関するガイドライン
の「６．９

第２版」

災害等の非常時の対応」から関連部分を抜粋すると、「（前略）自然災

害発生時には多数の傷病者が医療サービスを求める状態になり、医療情報システムが正常であったとしても通常時のアクセス制御下での作業は著しい不合理の発生が考えられる場合である。この際の個人情報保護に関する対応は、『生命､身体の保24

護のためであって、本人の同意を得ることが困難であるとき』に相当すると解せられる。」と記述されている。
平常時に閉鎖されていた情報が開示されるとはいえ、無制限に誰もがアクセス可能にするのではなく、開示を必要とする対象を設定し災害時に限ったアクセス手法を設定しておく。前述のガイドラインでは「非常時時用ユーザアカウントの用意」
として説明され、その使用の際は以下の４点を基本としてあげている。
・通常時の明示的な封印
・使用状態に入ったことの周知
・使用の痕跡を残すこと
・定常状態に戻った後は新しい非常時ユーザアカウントへ変更すること
上記の「使用状態」は、本書の第３章「３．１‑（４）−①

ブレークグラス機能の実装」の項で述べた「アクセス制限の緩和」の状態を指し、その状態にあることの周知と、制限が緩和されたことの痕跡を残すことが、セキュリティ・レベルを低下させざるを得ない開示状態を可能な限りコントロールしておくために必要ということである。
表４−１に平常時と災害時に想定されるログイン権保有者を整理する。災害時のみのログイン権保有者に対しては、災害時のアカウントとその利用法を伝達しておくことが必須となる。
【表４−１】
表４−１「平常時と災害時のログイン権」
平常時

災害時

○

○

関係職員

○（要本人同意）○

保健師○（要本人同意）○医師○（要本人同意）○医療従事者○（要本人同意）

○

関係職員

×

○

保健師

×

○

医師

×

○

医療従事者

×

○

住民
ＥＨＲ運用自治体
ＥＨＲ登録医療機関
他自治体
他医療機関

③

災害時開示についての利用者同意
ＥＨＲは利用を希望する住民が登録するものとして提案されており、登録時には個人情報の委託についての同意を得る。その際に、「災害時には登録者の生命、身体の保護のため、同意を得ずに情報を開示すること」に対しても、説明・納得・同意の手順を組み込むことが望まれる。
④

開示権限者の決定
昨年度の実験においては、システムを災害モードに切り替える権限者は、自治体

25

首長とした。しかし首長と連絡が取れない場合など、不測の事態を想定し段階的な権限者設定で備えることが望ましい。
⑤

災害時に開示する情報の区分け
ＥＨＲに格納されているすべての情報が医療措置に同様な必要度を持つものではない。医療従事者へのヒアリングからは、発生直後の急性期には以下の情報が必
要最小限の項目としてあげられた。ＥＨＲで管理している個人情報のなかから、これらの情報を「災害時開示情報項目」として区分けされるシステムとする。
・本人同定情報・外傷・疾病の種類と程度
・常用薬・平常時医療措置（慢性疾患など）の有無
確実な本人同定が、情報の開示と活用の基礎となるものであり、同定段階にはセーフティネットを組み込むことが必須となる。

（２）ＢＣＰの各フェーズにおけるＥＨＲ利活用モデル①

ＢＣＰとして事前に 周知しておく必要がある事項（平常時）
・ 平常時においては前項（１）であげた項目をＥＨＲ構築において装備、確認しておく。
・ 災害時利活用の内容と手法、なかでも個人情報開示について、各利用者・関連機関に周知、同意を得る。
・ 関係者による訓練を実施する。

サービスの利用を希望する住民A

自治体
健康推進課

サービス利用同意※災害時の個人情報開示に同意

役所

首長

保健センター
保健指導者

保健センター

医療機関

ＥＨＲ-ＤＢ

発動権限
代理移管体制等

利用申込

ＥＨＲシステム
加入

利用ID・
パスワード発行
ID
パスワード
健診受診

健診内容登録
健診情報
受領

印刷

健診
結果

健診
結果

受診
診療内容登録※他機関で患者同意
を得て参照

凡例

ＥＨＲサイトへ
住民用のID・
パスワードでログイン

システムでの処理・作業
アナログでの処理・作業
紙帳票

結果参照

DBへ登録されたデータ

健診情報
写真などのデジタル画像

保健指導結果トリアージタグ

図４−１−１「災害時ＥＨＲ活用

26

フェーズ①

平常時」

②

ＢＣＰ発動フェーズ

・ 予知可能な場合は、避難誘導が発動となる。その際、災害時要援護者のリスト
をＥＨＲデータベースから作成し、誘導担当者に通知する仕組みを組み入れることが可能なら有用と思われるが、第２章で述べた通り本人の同意を平常時に得る業務が、現時点では自治体の大きな課題となっている。
・ ＢＣＰ発動判断。首長あるいはそれに代わる権限者がＥＨＲを災害モードへ切替。
〈切替後〉
・ 被災者の情報を必要な機関に対して開示することが可能となる。
・ 後方支援医療機関など、平常時はログイン不可の機関が「非常時アカウント」
によりログインしデータ参照可能となる。
他都道府県
県庁・災害センター

ＥＨＲ利用住民（被災）

防災対策本部

役所

首長

救助関係者

後方支援

医療機関

ＥＨＲ-ＤＢ

対策本部設置

災害時モードへ切替

システムログイン
被災者・被災地情報
参照

被災者情報開示
支援要請

システムログイン
被災者・被災地情報
参照

被災者情報開示

救助・トリアージ実施
負傷者データ・
トリアージデータ登録

搬送・医療措置
被災者個別の常用薬情報参照

図４−１−２「災害時ＥＨＲ活用

27

フェーズ②

災害発生直後」

③

業務再開フェーズ

・ 被災情報の集積が進み、被災者個人の情報伝送のみならず、被災地全体の情報を一覧し救助や支援の効率化、災害医療に関する指示系統の一元化を図る。
・ 救助現場でのＥＨＲ情報活用にはデバイス操作の煩雑さなどが昨年度のヒアリ
ングなどで指摘されているが、位置確認・救助から医療措置に移った段階では、医療従事者が各種情報をある程度の大きさをもつモニター画面で参照すること、あるいはキーボード入力を要する場合は必要と想定される。
・ その際のセキュリティ強度、ログインを含むインタフェースからみてＰＣが適しており、ＰＤＡ的なもの、モバイルＰＣの準備と使用も合わせて検討すべきである。携帯は現場でのアクセスデバイスとしてセットで用いることが想定で
きる。
他都道府県
県庁・災害センター

ＥＨＲ利用住民（被災）

防災対策本部

役所

救助関係者

後方支援
医療機関

医療機関

後方支援

被災地全体情報↓全体的救助

ＥＨＲ-ＤＢ

被災地情報を参照し、医療活動を指示
エリア別、注力場所を選定

被災地情報を参照し、支援準備

被災者個人情報↓個人救助

救助・トリアージ実施
負傷者データ・
トリアージデー
タ登録(継続）搬送・医療措置
被災者治療において常用薬情報、トリアージ
データ、負傷部位画像を参照

凡例

医療措置を入力システムでの処理・作業
アナログでの処理・作業

後方支援病院への情報開示

紙帳票
DBへ登録されたデータ

被災者個人情報を参照
搬入被災者情報を取得

写真などのデジタル画像
トリアージタグ

図４−１−３「災害時ＥＨＲ活用

フェーズ③

28

災害発生後数時間」

最新の被災地数値・俯瞰情報により、救援物資・救護スタッフを手配し被災地に搬送

④

業務回復フェーズ

・ 応急医療活動から、被災者ごとのクリニカルパスにシフトするに従い、現場・避難所・被災地医療機関・災害拠点病院・後方支援病院などの間での情報伝送が利活用の中心となる。
・ 医療機関入院が決定した時点で、個人の情報は閉鎖される。
・ 避難所や仮設住宅での医療活動が開始され、入所者データは医療資源の配分等に活用される。

ＥＨＲ利用住民（被災）

防災対策本部

役所

救助関係者

後方支援
医療機関

医療機関

被災 地全体情報↓全体的救助

ＥＨＲ-ＤＢ

避難所、仮設住宅での医療活動を強化
被災地、被災者情報から医療資源を配分
現場でのＮＷ環境整備

被災 者個人情報↓個人救助

応急医療活動から、被災者ごとのクリニカル
パスにシフト

応急医療活動から、被災者ごとのクリニカル
パスにシフト

健診・既往歴データを参照

健診・既往歴データを参照

災害医療記録を入力

災害医療記録を入力

被災者受入れ病院決定で個人情報閉鎖

凡例システムでの処理・作業
アナログでの処理・作業
紙帳票
DBへ登録されたデータ
写真などのデジタル画像
トリアージタグ

図４−１−４「災害時ＥＨＲ活用

29

フェーズ④ 回復初期」

⑤

全面復旧フェーズ

・ 個人については、いわゆる災害医療から平常時の医療・健康管理へシフトする。
・ 例をあげれば、後方支援病院での医療措置を終え、かかりつけ医への通院に切り替わる。その際に診療サマリーをＥＨＲに格納することにより、電子記録で伝送、以降の診療や健康管理のデータとする。
・ 必要性の軽減によって、徐々に開示情報を閉鎖する。
・ ＢＣＰ終了判断。首長あるいはそれに代わる権限者がＥＨＲを平常時モードへ切替。
・ 災害モード中に開示した個人情報の閉鎖をチェックする。
・ 災害時使用の「非常時アカウント」を変更する。

ＥＨＲ利用住民（被災）

防災対策本部

役所

救助関係者

首長

後方支援
医療機関

医療機関

被災地全体情報↓全体的救助

ＥＨＲ-ＤＢ

必要性に応じ、徐々に情報開示を閉鎖

平常時モードへ切替

個人情報閉鎖をチェック

入力データ分析に
よって災害時医療活動を総括

被災者個人情報↓個人救助

入院から通院へ
医療措置記録を入力、被災者かかりつけ医へ
情報提供
避難所、仮設住宅、自宅などにおける保健活動に被災者
災害時データを活用

凡例
システムでの処理・作業
アナログでの処理・作業
紙帳票
DBへ登録されたデータ
写真などのデジタル画像
トリアージタグ

図４−１−５「災害時ＥＨＲ活用

30

フェーズ⑤

復旧期」

医療措置記録を入力、被災者かかりつけ医へ
情報提供

⑥

ＢＣＰ見直し・ 災害モード中に入力されたデータを分析し、エビデンスに基づいて災害時医療活動を総括
・ 各関連機関と連携して災害時のＥＨＲ運用を検討、改善点を抽出する。

自治体
健康推進課

ＥＨＲ利用住民役所

首長

保健センター
保健指導者

保健センター

医療機関

ＥＨＲ-ＤＢ
被災地全体情報↓全体分析・計画

各機関と連携してシステム運用を検討

個人情報↓個人診療︑健康管理

Ｃ

受療
既往歴、健診データを参照し診療

Ｃ

Ｃ

健診受診
Ｃ

Ｃ

健診データ入力

Ｃ

健診データを参照し、
保健指導

凡例

システムでの処理・作業
Ｃ

アナログでの処理・作業
紙帳票
DBへ登録されたデータ
写真などのデジタル画像
トリアージタグ

図４−１−６「災害時ＥＨＲ活用

フェーズ⑥ 再計画期（平常時）」

31

４．２

具体化のために

携帯電話活用のモデル

本項においては、具体的に住民が利用できる観点から、デバイスとして携帯電話を例に挙げ、ＢＣＰに基づいた各フェーズにおいて、どのようなＥＨＲの活用がありうるのかを考察する。
特に重要視したポイントは２つあり、そのひとつは、平常時におけるＥＨＲの情報からどのような情報を携帯電話に蓄積し災害時に活用できるかという点であり、もうひとつは、
災害時において携帯電話に蓄積したＥＨＲ情報活用時にセキュリティを確保した形で、医療救助関係者が利用できるかの点であった。
前者に関しては、災害直後に活用できるシーンと復旧活動、避難所等の救護活動時に活用できるシーンを想定して、それぞれのＢＣＰフェーズに当てはめて議論している。後者に関しては、災害時医療救助関係者にＢＣＰ発動時にのみ利用可能な「閲覧キー」を配布し、一時的に個人の携帯電話の情報を参照し活用する想定を行った。
下記に各フェーズにおける活用モデルをまとめた。

（１） 本モデル検討にあたっての前提事項① 携帯電話機および携帯電話アプリケーション
以下の機能を有していることを前提としている。なお、これらは、すでに技術的に実現できているもの、近い将来実現できると思われるものが含まれる。
・ ＥＨＲへアクセスし、災害時用ＥＨＲデータをダウンロードする機能
・ 携帯電話内に登録・記録された情報（安否情報、被災情報等）は、通信可能な状態の場合、リアルタイムで自治体へ送信。通信不可能な場合には、一時的に記憶され、通信可能となった段階で送信する機能
・ 記録されている情報を閲覧・更新する際、本人性を認証する機能
・ 各種信号を受信する機能を有し、それを契機として、携帯電話内に記録されたＥ
ＨＲ（災害時必要な情報のみ）が本人以外でも特別のキー（以下、「閲覧キー」という）を用いて閲覧可能となる機能
携帯電話事業者から送出される緊急地震速報、発信規制信号
デジタルテレビ放送事業者から送出される緊急放送波
・ 災害時、自治体から送出されるＥＨＲ開放信号を受信する機能、それを契機として携帯電話内に記録されたＥＨＲ（災害時必要な情報のみ）が本人以外でも閲覧
キーを用いて閲覧可能となる機能
・ 閲覧キーにて閲覧可能となった状態で、ＥＨＲに優先救助が必要な情報（慢性疾患の既往歴等）が含まれていた場合、イルミネーションが点滅し音が鳴り出す機
能（災害時優先救助アラーム）
・ 災害終結時、自治体から送出されるＥＨＲ閉鎖信号を受信する機能。それを契機として携帯電話内に記録されたＥＨＲが本人のみしか閲覧できなくなる機能（閲覧キーで閲覧できなくなる）

32

・ 災害時、自治体から送出される閲覧キーを受信する機能（医療・救助関係者等、あらかじめ認定された者のみが受信）・ 災害終結時、自治体から送出される閲覧キー無効化信号を受信する機能（医療・救助関係者等、あらかじめ認定された者のみが受信）②

自治体ＥＨＲの活用

自治体は、住民のＥＨＲを蓄積するサービスを提供し、日常の診療、健診、介護等において積極的に活用できる環境を整え、常に最新の住民ＥＨＲを保持しておく。本モデルでは、自治体サービスとしてのＥＨＲはすでにあることを前提としており、想定する
ＥＨＲとその活用の仕組みは以下の通り。
・ 住民が日々の診療、健診、介護サービスを利用した際、ＥＨＲの情報の流れは、
オンラインにて下記の通りとなり、ＥＨＲを最新の状態に保つ。また最終的に住民がその情報をダウンロードすることで、情報が還流される。
・ 住民→医療機関、健診機関、介護機関等→保険者→自治体→住民（ダウンロード）
・ 被災地域のＥＨＲサービス利用者に対して、管理者がＥＨＲ開放信号を送出するための機能を有する。また、あらかじめ登録されている医療・救助関係者の携帯に閲覧キーを送出する機能を有する。
・ 災害終結時、管理者がＥＨＲ閉鎖信号を送出するための機能を有する。また、あらかじめ登録されている医療・救助関係者へ閲覧キー無効化信号を送出する機能を有する。
・ 携帯電話から登録される被害情報、安否情報、位置情報等の集計・分析機能（２） ＢＣＰの各フェーズにおける携帯電話活用モデル① ＢＣＰとして事前に周知しておく必要があるもの（本モデルでは、平時を想定）（ア）自治体・ 災害時にＥＨＲの一部を本人以外に開放するにあたって、その開放基準をＢＣＰに盛り込んでおく。
・ 大地震発生時は、通信不能になる可能性が高いので、設定値を超えた場合にＥＨ
Ｒが自動開放される仕組みとすることが望ましい。（震度６弱以上場合、緊急地
震速報受信と同時に開放される等）33

図４−２−１「災害時ＥＨＲ活用

フェーズ①

平常時」

（イ）住民
・ 自治体が提供するＥＨＲ蓄積サービス利用に登録し、携帯電話に必要なアプリケーションやＥＨＲをダウンロードしておく。
・ 日々の生活の中で診療、健診、介護サービスを利用した後は、最新のＥＨＲをダ
ウンロードし、携帯電話に記録されているＥＨＲを更新しておく。
② ＢＣＰ実行フェーズ（本モデルでは、発災直前・直後（通信不能）を想定）（ア）自治体・ 大規模災害で多数の被災者が発生すると想定される場合、被災現場での医療活動を迅速かつ円滑におこなうため、被災地域の住民に対してＥＨＲ開放信号を送出する。
・ 現地へ赴いた医療・救助関係者が被災者のＥＨＲを活用を閲覧できるようにする
ため、医療・救助関係者に閲覧キーを送出する。
（イ）住民
・ 被災地域の住民は、自治体が送出したＥＨＲ開放信号を受信する。地震の場合は、携帯電話事業者から送出される信号（緊急地震速報、発信規制信号等）や、デジタルテレビ放送事業者から送出される緊急放送波を受信する。

34

・ これにより、ＥＨＲの一部が閲覧キーにより閲覧可能な状態となるとともに、災害時優先救助アラームも起動する。
・ 周辺の被害状況、安否情報等を登録・送信する（通信不能の場合、携帯電話内に一時保存される）。
（ウ）医療・救助関係者
・ 自治体が送出したＥＨＲ閲覧キーを受信する。
・ 被災現場で、閲覧キーを用いて重症・中等症患者、災害時優先救助アラームが出ている患者等のＥＨＲを閲覧、内容や身元の確認に応じた適切なトリアージおよび応急処置等を行う。

図４−２−２「災害時ＥＨＲ活用

フェーズ② 発災直前・直後」③ 業務再開フェーズ（本モデルでは、発災後数時間（通信随時回復）を想定）（ア）自治体・ 通信が随時回復してくるにしたがって、情報が集まってくるので、被害情報、安否情報の集計・分析機能にて状況を把握し、救護所や避難所の開設を行う。
（イ）住民

35

・ 周辺の被害状況、安否情報等を登録・送信する（一時保存されていた情報は、通信の回復と同時に送信）（ウ）医療・救助関係者
・被災現場で、閲覧キーを用いて重症・中等症患者、災害時優先救助アラームが出ている患者等のＥＨＲを閲覧、内容や身元の確認に応じた適切なトリアージ等
および応急処置を行った後、搬送先病院へ患者を搬送する。

図４−２−３「災害時ＥＨＲ活用 フェーズ③

発災後数時間」④ 業務回復フェーズ（本モデルでは、回復初期を想定）（ア）自治体・ 被害情報、安否情報の集計・分析機能にて状況を把握し、人的支援、物資の適正配置を行う。
（イ）住民
・ 安否情報等を登録・送信する。また、救護所や避難所などに移動した場合、位置情報も登録・送信する。

36

（ウ）医療・救助関係者
・ 重症・中等症患者を受け入れた病院では、閲覧キーにてＥＨＲを閲覧し患者の情報を確認。自治体ＥＨＲにアクセスし、該当患者のより詳細なＥＨＲを確認し、診療に活用する。
・ 救護所、避難所では、集まってきた被災者のＥＨＲを確認し、健康管理、感染症予防などを行う。

図４−２−４「災害時ＥＨＲ活用 フェーズ④

回復初期」⑤ 全面復旧フェーズ（本モデルでは、復旧期を想定）（ア）自治体・ 被害の収束とともに、ＥＨＲの閲覧の必要性がなくなった場合、閲覧キーにてＥ
ＨＲを閲覧できなくするため、被災地域の住民へＥＨＲ閉鎖信号を送出する
・ あわせて、医療・救助関係者へ閲覧キー無効化信号を送出する（イ）住民
・ 被災地域の住民は、自治体が送出したＥＨＲ閉鎖信号を受信する

37

（ウ）医療・救助関係者
・ 自治体が送出したＥＨＲ閲覧キー無効化信号を受信する⑥ ＢＣＰ見直し（本モデルでは、再計画を想定）（ア）自治体・ 各フェーズの時間軸の検証
・ ＥＨＲ活用実績の検証
・ 災害時に必要なＥＨＲの見直し
・ システムの機能面、運用面の検証

４．３ ヒアリングの結果と今後の課題
前項の住民の視点から見たＥＨＲ活用モデルをＢＣＰの観点からの検討結果を基に、自治体関係者（広島県、三条市、加古川市）災害時医療専門家（災害医療センター、岩手医科大学、広島大学）のご協力の下、ヒアリング活動を実施した。
ヒアリングの結果として、以下の様な指摘があった。

（１）活用可能なＥＨＲ情報
活用可能なＥＨＲ情報としてあげられたものには、個人の基本情報に加えて、①投薬情報、②かかりつけ医連絡先、③家族等身元引受人の連絡先があった。
①

災害時に服薬中の薬の情報があれば、医師であれば疾病の判断が可能であり、あえて疾病情報を知る必要はないこと②

慢性疾患患者の病歴や治療の情報は、かかりつけ医との連絡がつけば得ることが可能であり、被災後の患者さんの治療のためにも、必要な情報である。だだ
し、大規模な地震災害などで通信が途絶し、かかりつけ医と連絡が取れない場
合も当然想定しておくことが必要である。

③

現状では、意識のない重傷者等、連絡先が不明な場合には、警察等に確認している。その場合、家族等の連絡先が必要となる。

（２）災害時の医療情報システムの観点からの指摘
今回の「ＥＨＲ活用のモデル」全体として、個人の携帯電話におけるＥＨＲ情報活用としているが、自治体側、医療者側からの観点の捉え方が重要であることの指摘があった。
つまり、携帯電話を住民個人が使うツールとしてだけではなく、災害時の医療情報システ
ムの観点から検討が不可欠であるという指摘である。
①

被災者支援を目的とする場合の前線の救助を担当する医師や救助関係者への情報支援（必要とする物資等を把握できる等）②

重傷者を受け入れる災害拠点病院等の後方支援病院との情報連携のための仕組
み（自治体ＥＨＲの活用や連携など検討等）

38

③

救急医療と災害時医療はシームレスにつながり、線引きは難しい。（災害と救急の初期は不鮮明である）したがって、通常時の救急においても活用できる仕組み、そのような膨らみを持つ仕組み（救急医療情報システムとの連携等）（３）自治体ＥＨＲの活用という視点からの指摘
今回の検討モデルでは、想定している災害が、「通信が不通となる大規模な地震」のイメージと捉えられるが、災害にもいろいろな種類があり、自治体ＥＨＲの活用という視点では、風水害等の災害も視点に入れるべきであるという指摘があった。
①

台風等事前に被害が予測される風水害においては、災害発生前に、慢性疾患患者や高齢者を中心に、避難を勧告したり、必要な医療支援を考慮したりすることが可能である。

②

このようなシーンにおいては、ＥＨＲで事前に災害時要救護者を抽出し、早期の対策に活用できる可能性が出てくる。（しかし個人情報の利用には制約が多い）（４）実用の観点からの指摘
被災者特に災害時要援護者にとってはモデルの機能としては必要あるいは有効であるが、デバイス操作が困難であることが想定され、実用には、①正確性 ②簡便性 ③
速度 が求められるという指摘があった。
その他、具体的な技術論（通信不能時の閲覧キーの配布方法や収束時における閲覧キーの削除方法など）については、標準的な仕組みやその普及方法について、現段階においては、将来的な課題として残ることとなった。
以上、「具体化のための携帯電話活用モデル」としてＢＣＰのプロセスに沿ったシナリ
オを作成し、ヒアリング活動を実施したが、具体的に自治体や災害時医療専門家から求められているものは、「住民個人が持つＥＨＲ情報」の位置づけよりも、「自治体として活用可能なＥＨＲ情報」の整理と仕組み作りが優先されるべきであることが明らかになった。
今後の課題としては、被災地自治体におけるＥＨＲの活用の具体例を検討し、避難所等の住民に対し、ＥＨＲを利用した健康管理や疾病対策などの住民サービスを実施できる仕組みの検討や被災自治体以外へ避難した場合等においても、避難先自治体との連携によってＥＨＲを活用できる仕組みを検討するなどの観点が必要であることが明らかとなった。

４．４

総論

本章では、ＢＣＰに基づいたＩＣＴ活用モデルについて検討してきたが、なかでも災害時においてどのような医療情報が必要かを中心に議論、有識者からのヒアリングを実施してきた。今までの検討内容から、災害時医療において必要な情報は、いくつかの要素が影響していることが分かっている。

39

・ 災害の規模
・ 災害発生からの時間経過
・ 場所（被災現場、救護所、被災地内病院、災害対策本部、被災地外病院など）
・ 人（自治体職員、医師、看護師、保健師など）
・ 被災患者の状況（重症度）
上記の要素の組み合わせにより、必要な情報が異なってくるため、災害時医療に必要な情報とその情報取得者について断定的に定義することは難しい。
このようなことから、一定の条件のもと、災害時医療に必要な情報とその活用について整理した。

（１）情報取得者（誰が）災害時は、人命救助が最優先されるため、人命救助に関わる人物、すなわち「災害医療従事者」が妥当と思われる。ここでいう「災害医療従事者」とは、被災現場、救護所、病院、避難所など各ロケーションにて医療・救護活動に従事する医師・看護師等を指す。
（他自治体など被災地外から応援に来る医師、看護師を含む）
また、災害時には、自治体職員も人命救助の補助的役割を担うことが想定される。災害時に災害医療に関わる補助的役割を持った職員を「災害医療補助者」とし、災害医療従事者と同様に情報取得者として位置付ける。ここでいう「災害医療補助者」とは、医療衛生部局職員、保健師、救急救命士等を指す。（他自治体の職員は含まない）（２）災害時医療に必要な情報（どのような情報か）
本ＰＴでは、災害医療という観点に絞った情報について検討してきた。この観点において、昨年度の実証実験や今回のヒアリング結果から災害医療従事者および災害医療補助者が災害時に必要であると思われる情報をまとめた。【図４−４】
情報の種類を大別すると以下の通りとなる。
・ 災害発生から終結まで継続して必要となる情報（個人基本情報、身元引受人情報）
・ 災害発生以降、特に重症・中等症患者の迅速かつ適切な人命救助・治療に役立つ情報（トリアージ情報、投薬情報、かかりつけ医情報、アレルギー情報、慢性疾
患情報）
・ 被災住民の健康管理に役立つ情報（投薬情報、かかりつけ医情報、アレルギー情報、慢性疾患情報、既往歴）

40

図４−４「災害時医療に必要な情報」（３）情報の活用シーン
災害時において、災害医療従事者および災害医療補助者は、様々なロケーションにおいて活動することが想定される。本ＰＴで考える情報活用のロケーションは以下の通り。【表４−４−１】
表４−４−１ 「情報活用のロケーション」
ロケーション内容

被災現場

トリアージ、重症・中等症患者の一次救命処置をおこなう

救護所

一次救命処置を終え搬送されてきた重症・中等症患者に対して二次救命処置をおこなう。また、自力歩行で訪れた軽症患者等の応急処置をおこなう。

病院

一次もしくは二次救命処置を終え搬送されてきた重症・中等症患者に対して専門的な治療をおこなう。（被災内のみならず、広域医療搬送が実施された場合に搬送先となる被災地外の後方支援病院もこれに含む）

避難所

被災地域の住民の一時的な生活拠点

41

（４）情報の重要度
災害時医療に必要な情報、活用ロケーションを明確化してきたが、各ロケーションに
おいて情報の重要度が異なるということが昨年度の実証実験および今回のヒアリングにて明らかとなっている。各ロケーションにおける情報の重要度をまとめてみた。【表４−４−２】
表４−４−２

各ロケーションにおける情報の重要度
災害医療従事者および災害医療補助者から見た各ロケー
ションにおける情報の重要度

災害時医療に必要な情報

被災現場

救護所

病院

避難所

個人基本情報○○○○トリアージ情報（被災患者状況）

○

○

○

△

投薬情報

△

△

○

○

かかりつけ医情報

△

△

○

○

アレルギー情報

△

△

○

○

慢性疾患情報

△

△

○

○

既往歴

△

△

○

○

身元引受人情報（家族等）

○

○

○

○

[重要度] ○：高、 △：低
被災現場および救護所では、救命処置や安定化処置が中心であるため、傷病名や重症度等の内容が含まれたトリアージ情報が重要とされる。また、被災患者によっては、投薬情報、アレルギー情報、慢性疾患情報などはトリアージに影響を与えるものであり、トリアージ精度向上のための情報として有用であると考えられる。
病院では、症状に応じた専門的な治療行為がおこなえることから、より詳細な情報が重要であると考えられる。一方で軽症の患者および無傷の被災住民が集まる避難所は、
ある一定の期間、生活の場となるが、平時の生活環境と異なるため、健康な生活を送るために必要な情報が重要と考えられる。

（５）災害時医療に必要な情報の準備と活用
前項までで、災害時医療に必要な情報とその活用について述べてきた。災害時医療に必要な情報は、ブレークグラスの概念に基づき、災害発生から終結までの間、災害医療従事者および災害医療補助者がアクセスできる情報であり、平時はあらかじめ定
められたセキュリティポリシーに基づき管理されるべき情報である。
また、災害において発生するトリアージ情報以外の情報は、ＥＨＲデータ全体の一部であり、平時より蓄積されていることを前提としている。このため、ＥＨＲ−ＰＴにおかれては、本書で報告している災害時医療に必要な情報の内容を考慮し、検討・議論を進めていただけることを期待する。

42

第５章

自治体導入への留意点

本章においては、「災害時におけるＩＣＴの活用モデル」を自治体へ導入する際にどのような点で留意することがあるか。また、自治体内だけでなく、隣接する自治体や遠方にまで及ぶ関連機関との連携を行う必要性や活用モデルの導入における課題点などをまとめるものである。

５．１

自治体導入への目的について

平常時においては、第１章で記述の通り、ＥＨＲには医療・健診・介護などの情報が集積され、住民の健康増進サービスとして活用されることが想定される。平常時に対し大規模な災害が発生した場合、最低限必要とされる情報については、ＥＨＲから利活用が可能と考えられるが、・ 救急救命士や搬送先医療機関、医療対応者などが処置として必要な情報
・ 安否確認の際に必要な情報と手段
・ 災害の発生状況や被害状況
・ 関連する支援機関との連絡体制などのように、それぞれのフェーズ（第４章内の災害時ＥＨＲ活用図）に応じて求められる情報や伝達手段は異なる。自治体を中心とした災害等に対するシステムの取り組みが行われているが、ＥＨＲから集積した情報を災害時へ活用できるという面、災害時の情報を関連機関と連携して活用できるという面ではまだ進んでいない。自治体として、住民の安全と健康増進に努めるという役割からも自治体へ導入することを目的とし、中でも主な以下の３点を目的とする。

（１）広域連携の必要性
現状、健康増進や救急など様々なシステムが存在し、ある程度広域的に対応可能なものもあるが、その大半の機能する範囲としては個々の自治体内に限定された環境でのみ有効となる場合がほとんどである。また、既に自治体が導入しているシステム以外にも地域内の医療分野、介護福祉分野等、個人を取り巻く様々な情報が散逸している。今後はそれらの情報がＥＨＲとして集積・利活用されることが想定されるが、災害という面
では、自治体における情報の利活用以前の課題として、自治体内での情報連絡体制には一定の手続きが必要とされるものがある。災害時においてはその手続きが免除される場
合があるが、具体的な手段やどこで免除されるかという細かな点まで記されていない場
合があるということが今年度のヒアリング結果にも出ていた。よって、まずは災害時における自治体内の連絡体制を確立し、隣接あるいは遠方の自治体等への応援体制を確立する必要がある。
次に、被災地域となった自治体ではＥＨＲデータが利用できない環境であることも十分に考えられる。それには自治体同士のＥＨＲによる連携ができていることで、災害時

43における本モデルの利活用が可能となる。自治体内を越えて他地域の自治体や関係機関との連携における取組については、民間からの取組では難しく、住民の生命や財産を守る立場として自治体からの取組により、公平な立場として住民からも受け入れられやす
いのではないか。また、国との連絡体制、地域住民を包括的に守るなど、自治体としてのラインで連携を行い、従来以上の範囲で住民を守るという役目を自治体が果せることを目的とする。

（２）地域にあった利用形態の確立
地域の風土や特性に見合った防災対策を講じることができ、地域住民に最も身近に位置づけられる公的な機関としてあるのが自治体である。平常時においては自治体ごとに決められた災害への取り組みに対する運用やルールが構築されていれば、特に大きな問
題に至るまではないが、ＢＣＰを発動せざるを得ない災害に直面した場合、地域を越えての援助がなければ、復旧に至るまでに多くの被害や犠牲者が出ることになる。通信回線などのインフラが破壊された場合、情報収集は非常に困難な状態に陥り、被害状況の把握や復旧活動全般に支障をきたし、適切な支援活動が効率的に行えない。
災害への取り組みについては、自治体ごとに異なる地形や気候、さらには都市環境などにより、過去からの災害に対する被害状況は様々であるが、その結果を基に自治体ごとの策略がある。本モデルとしては、特定の災害に対応したものでなく、ＥＨＲを活用したあらゆる災害に活用可能なモデルである。その利用の形態は、自治体ごとに特化した災害に対応でき、地域としては、まだ未経験の災害について、被災体験のある地域との連携により、充実した支援体制を講じることもできる。よって、各自治体の特性に見合った体制を確立させ、広域的に見ても不足分を自治体同士でカバーできることを目的とする。

（３）格差のないサービス
ＥＨＲを日常的に利活用する延長として、ＥＨＲ内の必要な情報をそのまま災害発生時にも対応でき、データの動機あわせを改めて行う必要はなく、最新の情報が利活用できる体制が整うことになる。通信回線などのインフラが破壊された場合においても、それに代わる手段（携帯電話の活用、他自治体のサービス活用など）により自治体同士の連携が確立することで、地域外へ被災した場合や、時間的な制約に限られることがなく、
いつでもどこでもそして、地域による格差のないサービスを自治体として提供できることを目的とする。

５．２

導入における課題点（１）コンセンサスの確立
本モデルを自治体へ導入する際の課題として、関係機関とのコンセンサスの確立が考えられる。ＥＨＲにおいては、医療情報や健診情報、介護に関する情報等が集積されることより、自治体を始め、医師会や健診センター、医療機関などとのコンセンサスを得られているものと想定される。災害時については、【２章の図２−１を参照】の通り、様々

44

な種類が想定されるが、関連される機関として・ 保健衛生部門の団体、及びボランティア団体
・ 高齢者、障害者に対する介護施設、福祉施設及び関連団体
・ 水道局、電気通信会社、発電所、電話局などライフライン関連の団体
・ 道路交通、鉄道、船舶、航空関連の団体
・ 危険物取扱関連、自衛隊、レセキュー隊など救助活動団体などが考えられ、各機関とのコンセンサスの確立が行えるかが課題となる。しかし、全ての機関に対してのコンセンサスを確立させることは困難であるが、自治体として可能な限り多くの機関とコンセンサスを確立させておくことで、幅広い分野に至るまでの連絡体制を確立できる。また、支援する側となった場合においても、支援体制を明確にすることで、果たすべき役割を的確に行うことができる。ＥＨＲの構築時にも共通したことであるが、人が変わっても考えが引き継がれていく体制を確立させることが必要である。

（２）その他課題
災害時による支援体制の中で、受け入れ先となる急病センターや大病院においては集約許容範囲を明確にし、かつ、リアルタイムでその情報が更新されなければならない。
古い情報の下で搬送した場合、既に受け入れらなない状態では連携が取れているとはいかない。また、大規模な災害になるほど、受け入れ先ニーズは高まり、患者の搬送時に必要な情報が最新であるか、本人をどのように特定するか、地域外へ搬送する際の場所
や交通手段はどうすればよいかなど多方面での課題は残る。
また、災害時に必要な情報が利用できる環境も様々で、住民自身が安否情報を確認す
る場合、あるいは意識不明者の情報をどのように参照するか、特定端末からの利用に制限するかなど、データへのアクセス方法については、その人が本人か、またはその家族であるという定義をどのように行うかという課題がある。
災害時の情報に対する課題とは別に、災害の種別により、外傷、呼吸器系、循環器系などの人的被害に対する対応者や場所、必要な物品（麻酔、輸血、酸素、鎮痛剤、消毒
液、食料、水など）や人的支援などは一様ではなく、地域ごとの特性や実態に沿ったマ
ニュアル（ＥＨＲから災害時に利活用できる体制を含めたもの）が必要である。また、その体制に応じた実施訓練や人員配置を考慮した操作研修も必要となる。自治体内で行うもの、広域連携を想定して行うもの、災害の種別で行うものなど状況に対応した訓練が必要である。
上記内容とは別に、課題となりうる事項を下記に列挙する。
・

費用の負担について・

２４時間の３６５日運用の運用体制

・ニーズに合わせた改善改良

・

最新技術への対応（ＯＳやハードウェアの更新、陳腐化の防止）

45

・

非被災地域を含まない非一律的な閲覧キーの発動範囲と方法

・

衛星電話など災害時に活用できる通信手段の確立

５．３

災害と救急時（１）救急時の情報は災害時にも活用が可能
交通事故や急病などの救急において、病院へ搬送されるまでに救護を担当する際、最低限必要となる健康情報がＥＨＲに装備される。救命措置に対し、必要な情報項目を参照する運用としては傷病者のシステム加入時の事前同意でデータが蓄積される。このよ
うな救急の運用については、日常的に起こりうる可能性があり、搬送先病院への連絡体
制や受け入れ態勢がある程度取り決められている。一方、災害が発生した場合、自治体
や国レベルで災害対策本部が設置され、対策本部から災害扱いによる指揮命令のもと救急車は本来の救急としての役目を果たすこととなる。大規模な災害においては複数の自治体が被災地域となるが、情報源として、まずはＥＨＲからの利活用が考えられる。災害時においても被災地情報やトリアージ情報など特別な情報が記録されるが、その前提としてはＥＨＲが基本となる。

（２）災害と救急におけるフェーズに応じた連携範囲の策定
小規模または、狭い範囲における災害や救急時においては、事前に定められた防災対策マニュアル、もしくは緊急対応マニュアル的なものでカバーできるものとされるが、大規模な災害が発生した場合、被災した自治体だけでは対応ができなくなる。しかし、事前のＢＣＰの確立や本モデルの導入により、被災地の拠点病院から、非被災地域である二次三次の後方支援との連携が締結し、傷病者を迅速かつ的確に搬送することが可能となる。大規模災害発生時については、トリアージ情報により患者の搬送に優先順位をつけ、ヘリコプ
ターの出動や広域救急搬送などにより適切な処置に役立つシステムとなる。
地震、火事、風水害による建物の崩壊、ガス漏れ、水道管の破裂、生き埋めなど様々な被害が同時に起こり、消防隊員などによる限られた人員では対応できず、広域連携の支援体制が重要視される。消防機関のみならずレスキュー隊などの専門チームに対する要請のネットワーク体制を確立する必要がある。救出・救助に対して、現場での医療処置が必要となった場合、医師派遣の需要度が高まるが、医師の処置に至るまでにメディカルコント
ロール体制を充実させることや、救急救命士の育成、また、地域での救助活動も視野に入れ、市民救命士の育成も大きなポイントになる。
以上より、救急時の内容や、災害の規模によって必要とされる支援体制は異なるが、確立しておくべき関係機関とその体制については事前に想定可能である。よって、規模に応じてどこまでの範囲で連携が可能となるかを定めておくことが重要である。

46

５．４

システムの普及啓発（１）サービスを受ける側への啓発として・ 自治体による広報紙からの周知
・ ホームページや新聞などのメディアを利用した情報発信
・ 問い合わせ窓口の設置などによる柔軟な対応方法の確立
・ 住民向けの説明会の開催と意見交換の場
住民への啓発方法としては以上の様なことが考えられ、自治体からの住民へ向けたサービスとしての存在性をよりオープンな形で周知し、住民と直接コミュニケーションが図れるような形で連絡体制のとりやすい環境を設ける事が必要である。ＥＨＲを活用したサービスの延長として災害時にも安心して利用が可能であること、また、いつ直面す
るかもわからない災害時にも支援可能な関連機関の体制が確立されているという安心感をＰＲすること。それにより、平常時から災害時にも対応したサービスに自分が保護されていることが日常生活から根付く形で住民に浸透する。

（２）従事者への啓発として従事する者への啓発としては、効果的かつ計画的に行うために関係機関との連携は図
りつつ、実践的な活用要領を記載したマニュアルの作成と訓練や研修を通じた職員への周知徹底を行う。また、その計画やマニュアルについて遺漏や変更箇所がないかなど定期的な点検を実施する。システム面については災害時のみに操作可能となる機能があれば、操作方法も連絡体制も普段の教育なくしてはごく一部の者しか利用できなくなる可能性も考慮しておく必要がある。
各種災害において人的な被害や経済的な被害を軽減し、住民の安全と健康を確保する
ためには、自治体による広報活動も重要視されるが、家庭、学校、企業、公共施設などが連携して地域一体となった日常からの理解を深めることが必要である。
ヒト・モノ・カネだけが大規模にかけられ、サービスとして認知されなければ価値のないものと化してしまう。サービスは導入開始から継続的な運用を行うにあたり、その存在や必要性を従事者から受ける側にまで広くアピールすることが必要となる。サービスが利用な場所、時期や利用方法、被害を最小限に抑える方法など、いついかなる災害に対応するためには、啓発としても平常時からの取り組みが必須である。

47

第６章

ＮＷセキュリティプロジェクト

構成員・オブザーバー

一覧（１）構成員
プロジェクトメンバー

役

割株式会社エスビーエス情報システム

メンバー

エヌ・ティ・ティ・コミュニケーションズ株式会社

メンバー

株式会社エヌ・ティ・ティ・データ

リーダ

株式会社コミューチュア

メンバー

財団法人加古川総合保健センター

メンバー

ＮＰＯ法人医療ネットワーク情報センター

メンバー

株式会社三菱総合研究所メンバー

野津 勤（財団法人理工学振興会）

メンバー（２）オブザーバー
総務省
厚生労働省

48

介護ネットワークサービスプロジェクト
基本提案書

財団法人 全国地域情報化推進協会
アプリケーション委員会

2008 年 3 月
第 2.0 版

【目 次】

１. 検討の背景 ..................................................................................................................................................3
１．１． 介護サービス提供の現状 .......................................................................................................................... 3
１．２． 介護ネットワークシステム基本提案書の目的 ................................................................................... 5
２. 介護事業の問題点と解決策 ....................................................................................................................7
２．１． 介護事業の問題点 ....................................................................................................................................... 7
２．２． 問題解決のアプローチ..............................................................................................................................12２．３． 介護ネットワークシステムの提案..........................................................................................................16
３. 介護ネットワークシステムの検討......................................................................................................... 18
３．１． 介護ネットワークシステムの概要..........................................................................................................18
３．２． 介護ネットワークシステムの仕様..........................................................................................................19
３．３． コストの検討 ..................................................................................................................................................28
４. 介護ネットワークシステムの効果......................................................................................................... 35
５. 今後の課題 ............................................................................................................................................... 39
５．１． 次年度の検討課題 .....................................................................................................................................39
５．２． 将来の方向性...............................................................................................................................................40＜別添資料＞
別添１：先進事例調査
１．１． 東京都国民健康保険連合会 「国保連合会介護給付適正化システム」
１．２． 島根県 松江市 「介護情報メッセージ交換システム」
１．３． 兵庫県 加古川地域「二市二町コミュニティケアネットシステム」
１．４． 北海道 美唄市 「介護予防システム」
別添２：業務の流れ・情報の流れ＜ASIS・TOBE＞
別添３：介護ソフトベンダへのアンケート集計結果
別添４：「介護標準メッセージ」
４―１：データ定義ファイル（XML Schema）
４−２：データ項目構造（タグセット構造）

2１. 検討の背景
１．１． 介護サービス提供の現状
高齢者に対する生活支援は、戦後、主として低所得者等を対象として、行政による措置制度として行われていた。その後、高齢化の進展等による介護ニーズの増大に伴い、「高齢者保健福祉施策推進十ヶ年戦略」（ゴールドプラン）等が策定され、国・地方自治体が一体となって、計画的なサービス基盤の整備が進められてきた。そして、平成１２年には、利用者の選択によって各種介護サービスを利用することを可能とし、費用負担を含め国民全体で高齢者の介護を支えることを目的に、介護保険制度が導入された。
介護保険制度では、市町村が保険者として、資格管理、保険料徴収、要介護認定、支払い、介護サービスの整備等の介護保険の運営全般を行う。一方、高齢者への訪問介護や訪問入浴等の介護サービスの提供そのものは、介護支援事業者が策定したケアプランに基づき、指定を受けた社会福祉法人・医療法人・民間事業者・NPO 等の各介護サービス事業者が行う。
介護保険制度をベースとして提供されている現在の介護サービスの特徴を以下に示す。

（１） 連携して提供される介護サービス
利用者が介護サービスを受けるにあたっては、図１−１に示すように、市町村、介護支援事
業者、地域包括支援センター、各種介護サービス事業者、国保連合会等多くの関与者が存在し、それぞれが連携して介護サービスを提供している。（介護サービスの給付を受けるには、それ以前に、要介護認定等を受ける必要があるが、さらに関与者が多くなり、複雑になるため、今回の図からは省く）（２） 既存の情報システムが存在する介護事業者
介護保険制度は、情報化を前提にした保険制度である。例えば、市町村が実施する要介
護認定では、共通の一次判定ソフトが導入され、合理化が図られている。また、国保連合会の報酬支払いもシステム化されており、介護サービス事業者から国保連合会への報酬請求も電子データが前提となっている。
そのような中、介護支援事業者、地域包括支援センター、介護サービス事業者の情報化の状況としては、介護サービス計画作成、給付管理、報酬請求を主目的として、ほとんどの介護事業者で、コンピューターシステムが既に導入されている。また、介護支援事業者、地域包括支援センター、介護サービス事業者からの国保連合会への報酬請求は、図１−１に示すように、ネットワーク（INS64）を介して電子的に行われており、医療保険とは大きく異なっている。

3

⑤介護サービスの提供

要介護者
要介護者
（要支援者）（要支援者）

点線：人や紙の流れ実線：電子情報の流れ

介護サービス事業者A
介護サービス事業者A⑤介護サービスの提供⑦提供票（実績）
から請求書を作成

市町村
市町村
④計画書・
提供票の入力
②計画書の提出・ 説明※ほとんど提出されていない

計画書

計画書

給付実績

介護支援事業者
介護支援事業者(地域包括支援センター)(地域包括支援センター)⑥提供票（実績）
の提出

提供票
（実績）

介護サービス事業者B
介護サービス事業者B

計画書
提供票 ③計画書・提供票
の提出
（予定）

①計画書・提供票
の作成

提供票

④計画書・
提供票の入力

（実績）⑦提供票（実績）
から請求書を作成⑥提供票（実績）の提出⑧提供票（実績）
から給付管理票を作成
給付管理票

請求書

INS64
国保連合会
国保連合会

図１−１ 介護サービス提供の概要（３） ますます重要となる保険者の役割
少子高齢化の進展に伴い、介護保険導入後も要介護者数は急増している。具体的には、
図１−２に示すように、要支援 1〜要介護 5 までの認定者数は介護保険制度の始まった平成
12 年 4 月では 2,181,621 人であったのに対し、平成 19 年 7 月現在では 4,465,205 人の 2 倍になっている。これに伴い、介護給付費も増加の一途を辿り、平成 12 年 6 月の集計（厚生労働省 介護保険事業状況報告 月報より抜粋）では 2,200 億円程度であったのに対し、平成 19
年 7 月の集計（厚生労働省 介護保険事業状況報告 月報（暫定版）より抜粋）では 4,900 億円程度となっている。
このような中で、保険者である市町村は、資格管理、保険料徴収、要介護認定、支払いといった保険事務の運用だけでなく、保険者として、地域全体の介護サービスの需要と供給の調整、さらには設計といった介護事業の経営を行っていくことが求められている。つまり、介護
給付費の無制限な増加に歯止めをかけつつ、適切な費用負担のもと、ニーズに対応した介護サービスを提供する介護事業の「経営」としての役割がより一層重要性を増している。

4

5,000

(千人)
4,284

4,500
4,000

3,759
3,353

3,500

要介護５
要介護４
要介護３
要介護２
要介護１
要支援

2,884

3,000
2,500

4,404

4,065

2,498

2,000
1,500
1,000
500
0
平成12年 平成13年 平成14年 平成15年 平成16年 平成17年 平成18年

図１−２ 要支援・要介護者の要介護度別認定者数の推移【出典：厚生労働省 介護保険事業状況報告 月報（暫定版）】※ 各年 12 月分の月報より（平成 18 年分の「経過的要介護」は「要支援」に含めた）

１．２． 介護ネットワークシステム基本提案書の目的
本基本提案書は、(財)全国地域情報化推進協議会にて推進している「自治体で共通利用が可能
な公共アプリケーションの整備」の一環として、介護による地域の高齢者の生活の質の向上に向けて、市町村による介護事業経営の支援と介護サービスの適切な提供を支援する「介護ネットワークシステム」の具体化を行うものである（図１−３）。
本基本提案書は、平成 18 年度に引き続き、介護ネットワークプロジェクトが中心となってまとめている。平成 18 年度は、介護サービスにおける問題点を分析し、市町村の介護事業経営の支援と個々の介護サービスの適切な提供を支援する「介護ネットワークシステム」の必要性をまとめた。
今年度は、「介護ネットワークシステム」の整備は、個々の自治体のみならず、全国の自治体の共通の課題であること、また、市町村の枠を超え、介護事業者等の民間も含む地域の様々な主体との連携が必要であること、さらには、社会全体のコスト低減のためには、一定の標準仕様を示すことが重要であると考え、「介護ネットワークシステム」の考え方及び標準仕様についてまとめた。
今後、本基本提案書により、自治体と地域の事業者とが連携し、高齢者の生活の質の向上に向けた「介護ネットワークシステム」の検討に取り組んでいただければ幸いである。

5

介護を通じた地域の高齢者の生活の質の向上

地域の介護事業の設計及び経営

地域の介護サービスの円滑な提供

介護ネットワークシステム
図１−３ 基本提案書の目的

なお、本基本提案書の本文では、各介護事業者や介護帳票等の名称を表１−１のように定義する。「介護予防」という言葉は、「予防給付」（要支援１・２を対象としたサービス）と「介護予防」（要介護認定に至るのを防ぐ施策）の 2 側面があるため、区別して表記する。
また、予防給付に関わる名称の内、本提案内容で既存の介護サービスと同様の扱いとなるものに関しては、既存の介護サービスの名称と同様の表記とする。
表１−１ 各種介護情報の定義＃

介護情報名称

本文での記載１

新予防給付：要支援１・２を対象としたサービス

予防給付

２

介護予防事業：要介護認定に至るのを防ぐ施策

介護予防

３

居宅介護支援事業者（居宅介護予防支援事業者）

居宅介護支援事業者

４

地域包括支援センター

地域包括支援センター

５

介護サービス事業者（介護予防サービス事業者）

介護サービス事業者

６７８

要介護者：要介護１〜５（介護給付）

要介護者

要支援者：要支援１・２（予防給付）
居宅介護サービス計画書（１表、２表、３表）
介護予防サービス・支援計画表・週間サービス計画表

計画書
提供票

サービス提供票・別表＃必要に応じて提供票（予定）、予防サービス提供票・別表

提供票（実績）と表記

6

２. 介護事業の問題点と解決策
２．１． 介護事業の問題点
現状の介護事業の問題点を確認するため、現状の介護サービス提供の流れを整理すると共に、
市町村と介護事業者の主要な関与者に対して、現状と問題点についてヒアリングを行った。

（１） 市町村の介護事業の設計・経営における問題点
前述したように、市町村は、介護保険の保険者として、資格管理、保険料徴収、要介護認
定、支払い等の介護保険の事務運営に加え、事業者の指導や介護サービスの需給調整を行う介護事業の経営が求められている。特に、要介護者数が爆発的に増加している現状では、介護給付費の無制限な増加に歯止めをかけ、被保険者や要介護者の適切な介護保険料・介護費用の負担のもと、ニーズに対応した介護サービスを提供する介護事業の経営の観点がより一層重要性を増している。この介護事業経営の役割には様々なものがあるが、重要なものとしては、①地域の介護サービスの責任者として、個々の要介護者に対して適切な介護サービスが提供されているかを管理・指導する、②介護事業の経営者として、地域に必要な介護サービスを常に把握し、サービス誘致等の供給調整を行ったり、要介護認定に至ることを防ぐ介護予防活動を行うことで需要そのものの調整（削減）を行う 2 点がある。
この 2 点の現状と問題点に関して、市町村へのヒアリングを行った。

①個々の要介護者への適切な介護サービスの提供に向けた管理・指導
まず、個々の要介護者への介護サービスの「量」の管理の観点では、市町村は、介護事業者が介護サービス提供後数ヵ月後に各都道府県国保連合会より送付される介護サービスの給付情報を受け取っている。しかし、大部分の市町村では、サービスの総額（総量）を認識するのみで、個々人が利用したサービスの確認までは手が回っていない。また、国保連合会の給付適正化システムにより、不適切な給付額を抽出することも一部で行われているが、あくまでも「形式上」不適切と考えられるサービスをあぶりだすのみである。さらに、一部の市町村では、国保連合会より送付される介護サービスの給付情報をベースに、本当に当該介護サービ
スを利用したか否かの確認の手紙を要介護者に送付しているが、数ヶ月経ているため、要介護者が利用の有無を確認するのが難しく、十分なチェックができない状況である。
次に、「質」の管理の観点では、図１−１に示したように、本来市町村に提出されるべき計画書が提出されていないことが多いため、個々の要介護者への介護サービスの内容（質）は市町村にとって把握する手段がなく、介護サービスの質の管理・指導は、ほぼ皆無の状況である。また、たとえ提出されたとしても、紙帳票のままでは、活用するマンパワーがないのが現状である（よって、計画書提出のフォローもあまり行われていない）。
つまり、現状は、サービスの有無（量）を確認するにあたっても、提供票のタイムリーな捕捉（見える化）ができておらず、サービスの内容（質）を管理するにあたっても、計画書といった質を管理する情報の捕捉（見える化）がそもそもなされておらず、結果として、市町村は、適切な介護サービスの提供に向けた管理・指導ができていない。

7

②介護事業の経営者として地域の介護サービスの需給調整
まず、「供給の調整」に関してであるが、大部分の市町村は、3 年に 1 回の介護保険事業計
画作成の際にはじめて、介護サービスの給付情報から利用された介護サービス量を調査し、傾向を分析することで今後の必要量を把握したり、市町村によっては、高齢者アンケートを行
い、介護サービスの潜在ニーズも加えた上で、必要量を把握したりしている。しかし、介護サービス事業者の介護サービスの提供自体が要介護者の急激な増加に追いつかないことに加え、3 年に 1 回の計画策定時のみの突発的要求には介護サービス事業者も対応できるはずもないことから、要介護者数や利用サービス量等の数字データや科学的根拠をベースにした継続的な「供給量の調整」には程遠い状況である。
一方、「需要の調整（削減）」は関してであるが、要介護者数の増加による介護給付金の増
大が財政を圧迫している現状では、介護予防活動等の「要介護者の数」そのものを減らす活動は喫緊の課題であるが、介護予防活動まではなかなか手がまわっていない状況である。また、たとえ介護予防活動を行っていたとしても、数字データや科学的根拠のない無手勝流な予防事業では、大きな効果は上げられない。
つまり、現状は、介護サービスの供給調整にあたって不可欠な過去の給付情報の継続的な管理ができておらず、また、潜在ニーズを把握する唯一の手段である計画書の補足ができていないため、調整以前の必要量の予測ができない。さらに、介護予防（需要の削減）にあたっては、そもそも介護予防事業まで手がまわっていないのであるが、根拠に基づいた予防給付（身体状況に応じた予防サービスの提供）を行う際の前提となる予防の計画書の継続的な補足ができておらず、結果として、市町村は、介護サービスの需給調整には至っていない。

（２）介護事業者間の情報連携における問題点
現状の介護サービスの提供者である介護サービス事業者と介護支援事業者における計画書・提供票等の紙帳票の流れを整理し、問題点を机上検討すると共に、介護事業者にヒアリングを行い、問題点の確認を行った。紙帳票の流れの概要と問題点を図２−１に示す。
紙帳票の流れとしては、まず、介護支援事業者（地域包括支援センター）が作成した計画書や提供票（予定）を介護サービス事業者は受け取り、要介護者にサービスを提供する。そして、介護サービス事業者はサービス提供後に提供実績を記入した提供票（実績）を介護支援事業者に提出するというものである。なお、計画書の認定期間中における変更、月途中における提供票（予定）の変更は、介護支援事業者（地域包括支援センター）から介護サービス事業者に対して行われる。ここで重要なことは、介護サービスでは、1 人の要介護者に対して複数の介護サービス事業者が関わるため、非常に多数の帳票が発生するということである。また、計画書の認定期間中における変更、月途中における提供票（予定）の変更も、頻繁に発生するのである。
ヒアリングによって明らかになった介護サービス提供における事務処理上の問題点としては、まず、介護支援事業者は、各種帳票の印刷・仕分け作業が膨大であるとともに、受け取った実績を介護ソフトに入力する手間が発生するということがあげられる。
一方、介護サービス事業者は、受け取った帳票の内容を介護ソフトに入力する手間が発生
8するとともに、月途中における提供票の変更印刷の手間が発生するということであった。

介護支援事業者
介護支援事業者(地域包括支援センター)(地域包括支援センター)

介護サービス事業者
介護サービス事業者Ａ
Ａ

計画書
提供票（予定）計画作成

印刷
提供票(実績)印刷

ﾃﾞｰﾀ入力再入力
実績報告

実績報告

（手渡し、FAX等）

仕分け

介護サービス事業者 Ｂ
介護サービス事業者 Ｂ

計画書
提供票（予定）ﾃﾞｰﾀ入力再入力
印刷

送付
提供票(実績)

修正・再送

実績報告

実績報告

（手渡し、FAX等）
介護サービス事業者
介護サービス事業者Ｃ
Ｃ

実績確認

計画書

ﾃﾞｰﾀ入力再入力

提供票（予定）

実績入力

印刷
実績報告

提供票(実績)実績報告（手渡し、FAX等）＜問題点＞
・介護支援事業者：1 人の要介護者に対して複数のサービス事業者が関わるため、非常に多数の帳票の印刷・仕分け作業が発生する。また、変更時や実績入力の手間も発生する。
・介護サービス事業者：紙で受け取った帳票の情報を自事業所で管理する介護ソフトに入力する手間が発生する。変更時には、印刷の手間も発生する。

図２−１ 現状の介護事業者間の情報の流れと問題点

9これらの問題点の原因を探るため、情報の入出力に着目し、現状の介護サービスにおける計画書・提供票の入出力の可視化を、DFD（注１）を用いて行った。なお、DFD の作成においては、「流れている情報が電子データなのか紙なのか」、「処理がシステムで行われているか手作業で行われているのか」を明確化するために、電子情報については、太字下線で表記し、紙情報は太字で表記した。また、主に電算処理を行っている機能は濃い網掛けの楕円、部分的に電算処理を行っている機能は淡い網掛けの楕円、手作業で行っている機能は、白い楕円で表記した。

（注１）：ＤＦＤ（Date Flow Diagram：機能情報関連図）
各業務を構成する「機能」と、それぞれの間を流れる「情報」をシンプルに示す表記方法である。
「機能」は楕円で、機能間を流れる「情報」は矢印で、外部の関与者（外部環境）は長方形で、「情報」の一時的な貯蔵（時間滞留）は２本線で表記する。現状の組織・実現手段等に惑わされずに、純粋に業務を「機能」と「情報」で整理する表記方法である。
以下に、ＤＦＤのサンプルを説明と共に示す（図２−２）。
２．介護支援事業者 DFD レベル0

サンプル

市町村
要介護者
訪問調査 結果情 報

外部環境を示す

業務名を示す介護サ ービ ス事業 者

介護サービ ス計 画書情 報
サービ ス担当者 会議開 催通知 情報
介護サービ ス内 容情報

訪問調査 情報
介護サービ ス計 画書情 報
介護サービ ス計 画書情 報
介護サービ ス提 供票情 報

認定情報
介護計画 作成依 頼情報

２ 計画 書作成
認定情報
介護サービ ス計 画作成 依頼情 報

介護サービ ス計 画書情 報

３ 依頼・調 整

１ 受付
介護サービ ス計 画書情 報

介護サービ ス提 供票情 報

介護計画台帳サービ ス提供票台帳

介護サービ ス提 供票（実績）情報介護サービ ス計 画書情 報
介護サービ ス提 供票情 報

情報の滞留を示す

４ 給付 管理

情報名及び、情報の流れを示す
給付管理情報機能を示す
国保連合 会

図２−２ ＤＦＤサンプル

10

ＤＦＤの一例を図２−３に示す（介護サービス提供業務全体のＤＦＤは別添資料に示す）。
これらＤＦＤの分析より、問題点の原因は、介護事業者（介護支援事業者、地域包括支援センター、介護サービス事業者）間で受け渡しする計画書、提供票は、各介護事業者のコンピューターシステムを用いて、電子的に作成されているにもかかわらず、介護事業者間の伝達は、電子化された計画書・提供票を一旦紙に出力し、郵送・ＦＡＸ・手渡し等を用いて行われている
ことがわかった。
そのため、情報の出し手には、紙出力のための手間が発生するとともに、仕分けにも大きな手間が発生している。一方、受け手側では、計画書・提供票をコンピューターシステムへ再入力しなければならず、その手間が発生するだけでなく、転記ミスも発生しているのである。

２．介護支援事業者 D FD レベル0
市町村
要介護者

訪 問調査 情報介 護サー ビス承 諾情報
介 護サー ビス計 画書承 諾情報

介護サービ ス事業者

介 護サー ビス計 画書情 報
サ ービス 担当者 会議開 催通知 情報介 護サー ビス内 容情報

訪 問調査 通知情 報介 護サー ビス情 報介 護サー ビス計 画書情 報
サ ービス 担当者 会議開 催通知 情報介 護サー ビス計 画書情 報
介 護サー ビス提 供票情 報

２ 計画書作成認 定情報介 護サー ビス計 画作成 依頼情 報介 護サー ビス計 画書情 報

認 定情報介 護サー ビス計 画作成 依頼情 報

３ 依頼・調整介 護サー ビス計 画書情 報

１ 受付介 護サー ビス提 供票情 報

介護計画台帳内部で介護ソフトを用いて電子的に計画書・提供票を扱っているにも関わらず、外部とは、紙での受け渡しとなっている。

サービス提供票台帳
介 護サー ビス 計画 書情報

介 護サー ビス提 供票情 報

介 護サー ビス提 供票（ 実績） 情報

４ 給付管理給 付管理情 報

国保連合会
凡例

機能

：主に電算処理して い る機 能：部分的に電算 処理して い る機能：電算処理 を行って いな い 機 能

提供票（実績）を介護ソフトに入力する手間が発生している。
明 朝 体細 字 ：電 子以外 の情報
情報の滞留

情報 名： ゴシッ ク太字 下線 ：電子情報＜問題点の背景＞
・各事業者の内部では、介護ソフト等を用いて電子的に帳票の作成を行っているにも関わらず、外部とは紙での受け渡しとなっている⇒情報の出し手：紙出力のための印刷及び仕分けの手間が発生⇒情報の受け手：紙の情報を介護ソフトに入力する手間が発生（転記ミスの可能性）

図２−３ DFD による情報の整理と問題点の原因（介護支援業務における例）

11

２．２． 問題解決のアプローチ
前述の介護事業の問題点を以下に整理する。

＜問題＞
・保険者である市町村が介護事業の設計・経営を行うために不可欠な介護情報が把握できていない。
（情報に基づいた介護事業設計・経営ができない）
・介護事業者間の介護情報の出力・再入力に膨大な手間がかかっている。

これらの問題点を解決するためには、大きく以下の 2 点を実現する必要がある。

＜解決の方向性＞① 市町村の介護情報の適切な形での見える化（市町村が計画書・提供票を電子データで入手、ふさわしい形に加工できるようにする）② 介護事業者間の情報連携（介護事業者が計画書・提供票を電子データで受け渡しできるようにする）

解決策の検討に当たっては、上記 2 点の実現の検討に向けて、いくつかの先進事例での取り組みを参考に、具体化を行った。具体的には、介護事業者間の情報連携における解決事例として、（１）島根県松江市の「介護情報メッセージ交換システム」、（２）兵庫県加古川地域の「二市二町コミュニティケアネットシステム」を、市町村の介護情報の見える化に関しては、（３）
国保連合会の「給付適正化システム」を参考にした。なお、先進事例のヒアリング詳細に関しては、巻末に別添資料として添付する。

（１） 島根県松江市「介護情報メッセージ交換システム」
島根県松江市では、平成 14 年度に経済産業省のモデル事業で介護事業者間の情報共有（計画書・提供票の共有）を目的に、各介護事業者と保険者を INS64 回線で結び、共有サーバと接続する「介護情報メッセージ交換システム」を構築している。（図２−４）
モデル事業終了後もシステムの見直しを行っており、多くの介護事業者がシステムに参加している。
本システムにより、介護事業者のスムーズな情報連携が実現できている。さらに特筆すべ
きは、情報システムだけでなく、実際の人を含めた社会システムとして運用されており、情報の連携が介護サービスのよりスムーズな連携を生んでいるという点である。
一方、課題としては、INS64 という比較的古い回線であり、今後の技術的な展開が必要なこ
12

と、市町村での適切な介護サービス提供に向けた情報分析が挙げられる。

松江市

配信サーバ

事業者固有情報の取得◇ケアプラン情報◇サービス提供時の
利 用者情報INS回線による独自ネットワーク

居宅事 業所

サ ービス提 供事業所

主治医

簡易ソフト

簡易ソフト

簡易ソフト

介護ソフト

介護ソフト

意見書ソフト

利用者情報の共有（事業者間連携）◇計 画書 、サービス提 供票 、主治医意見書・訪問調査情報 （居宅のみ）◇在 宅生 活療養ノートによる経過 記録及びケアチームとしての意見◇専 門家 （主治医）からのアドバ イス【出典：松江市「介護保険課提供資料（2007 年 9 月提供）」】
図２−４ 「介護情報メッセージ交換システム」全体概要図（２） 兵庫県加古川地域「二市二町コミュニティケアネットシステム」
兵庫県加古川地域（加古川市・高砂市・稲美町・播磨町）では、利用者へのよりよい介護サービスの提供を支援するために「二市二町コミュニティケアネットシステム」を運用している。介
護事業者間で要介護者の状態情報を共有することでの介護サービスの質の向上や、介護支援事業者が介護サービス事業者のスケジュール情報を WEB 上で確認・登録することでの提供票の作成・管理の事務処理の軽減を実現している。
一方、課題としては、介護実績情報やケアカンファレンスなどの内容を要介護者や家族が家庭から介護情報を参照する場合のセキュリティ面の課題や、加古川地域以外の介護事業所との連携を行う場合の運用方法の明確化といったことがある。

13

（３） 国保連合会「介護保険給付適正化システム」
地域の介護情報を市町村が把握できず、需給調整が出来ていない問題点の解決策として、
あくまでも「需要の調整（削減）」の「不正請求額の削減」のみであるが、前述の国保中央会が開発した「介護給付適正化システム」がある。
都道府県国保連合会では、介護事業所から送付された請求情報や都道府県の事業所情報等を「介護保険給付適正化システム」を用いて集計した結果を市町村に提供している。（表２−１）
これにより、市町村では、提供された集計情報を基に介護サービス提供の実態調査の実施や市町村の管轄区域におけるサービス提供状況の把握を容易に行うことが出来る。
一方、課題としては、事業者間の情報連携は対象外なこと、また、分析のもととなるデータ
は、サービス提供月から数ヶ月後になり、必ずしもタイムリーではないこと、さらに計画書のデータは含まないため、適正なケアプランが策定されているかといった「質を加味した額の削減」に踏み込めないといったことがある

14

表２−１ 介護給付適正化システムの主な情報提供項目＃

提供情報項目

提供先

１

更新認定被保険者一覧表

保２

サービス計画費作成体制状況一覧表

保/県３

運営基準減算状態の状況把握表

保/県４

訪問介護サービス提供責任者数の状況一覧表

保/県５

定員超過・人員基準欠如状態の継続表

保/県６

定員超過・事業所一覧表

保/県７

介護支援専門員あたり給付管理票作成状況一覧（都道府県向け）

県

８

介護支援専門員あたり給付管理票作成状況一覧（保険者向け）

保

９

１種類サービスによるサービス計画一覧表

保/県

１０

同一・近似サービス事業所一覧表

保/県

１１

給付急増事業所一覧表（都道府県向け）

県

１２

給付急増事業所一覧表（保険者向け）

保１３

支給限度額一定割合超一覧表

保/県

１４

要介護度の偏りがある事業所一覧表

保/県

１５

福祉用具貸与一覧表保/県

１６

提供サービス１回あたりの単位数に偏りがある事業所一覧表

保/県

１７

支援事業所とサービス事業所の関係一覧表

保/県

１８

事業所の請求等決定状況一覧表

保/県

１９

要介護状態区分の変更履歴

２０

給付詳細情報一覧表

保/県２１

事業所別サービス状況一覧表

保/県

２２

受給者別給付状況一覧表

２３

事業所別サービス状況一覧表（年度）２４

受給者別給付状況一覧表（年度）

保２５

適正化等による申立件数・効果額（都道府県向け）（総括表・明細表）

県

２６

適正化等による申立件数・効果額（保険者向け）（総括表・明細表）

保２７

認知症対応型共同生活介護入居者一覧表

保２８

大規模事業所減算請求状況一覧表

保/県

２９

居宅介護支援請求状況一覧表（総括表・明細表）

保/県

３０

訪問介護における特定事業所加算請求状況一覧表

保/県

３１

他保険者利用の地域密着型サービス一覧表

３２

全体総括表

保/県

３３

全国平均・連合会内平均値

連合会

３４

介護報酬支払額上位事業所リスト

県

３５

全事業所支払額リスト

県

保

保
保/県

保

【出典：国保中央会「国保連合会介護給付適正化システム＜提供情報活用マニュアル＞」】
15

２．３． 介護ネットワークシステムの提案
上記のような先進事例を踏まえ、市町村の地域の介護情報の見える化を行い、事業者間の情報連携を行うため、「介護ネットワークシステム」を提案する（図２−５）
介護ネットワークシステムは、都道府県・国保連合会・市町村等に共有サーバを設置し、市町村、居宅介護支援事業者、地域包括支援センター、各種介護サービス事業者をネットワークで接続する。
共有サーバへは、介護支援事業者（地域包括支援センター）が、計画書・提供票（予定）を、各
種介護サービス事業者が、提供票(実績)をそれぞれ登録する。
登録された情報は、市町村、介護支援事業者、地域包括支援センター、各種介護事業者のそれぞれが、設定された権限に従い取込ことができる。
これにより、介護事業者間のスムーズな情報連携、市町村における地域の介護情報の把握を実現する事が可能となる。

市町村
市町村

介護サービス事業者Ａ
介護サービス事業者Ａ

計画書・提供票の取込

計画書・提供票（予定）の取込

ネットワーク
介護支援事業者
介護支援事業者(地域包括支援センター)(地域包括支援センター)

計画書・提供票（予定）の登録

都道府県・国保連合会・
都道府県・国保連合会・
市町村等
市町村等

提供票（実績）
を登録

共有サーバ
計画書・
提供票（予定）の取込

提供票（実績）の取込

介護サービス事業者Ｂ
介護サービス事業者Ｂ

提供票（実績）を登録

図２−５ 介護ネットワークシステム概要図

ここで、共有サーバは、コストの観点及び介護事業者が複数の保険者に介護サービスを提供するという業務特性から、単独の保険者で利用するのではなく、複数の保険者で共用とする形態が望ましい。そのため、共有サーバの設置場所も、介護事業者を管理する都道府県、審査支払を行っている国保連合会、さらには広域連合等がふさわしいと考える。

16

なお、先進事例調査の「介護給付適正化システム」で国保連合会から市町村に対して提供されている集計情報と「介護ネットワークシステム」で市町村が入手できる介護情報の差異点を、表２−２に示す。あくまで「介護ネットワークシステム」は、地域の適切な介護サービス提供を主眼としており、改善に向けたアクションを起こすことが可能なタイムリー性と適切なケアプランの立案と実施（計画書と提供票）の把握指導に重点を置いている。

表２−２ 「介護給付適正化システム」と「介護ネットワークシステム」との差異点
システム名称

提供する情報の種類
給付管理票、明細書（請求情報）、受給者情報、給付適正化システム

事業所情報、医療レセプト（老人保健分）を基にし情報の提供時期
サービス提供月から３〜４ヵ月後た集計情報（突合、縦覧等）

共有サーバに登録されてい介護ネットワークシステム

計画書・提供票（予定/実績）

るデータをリアルタイムに
入手可能

17

３. 介護ネットワークシステムの検討
３．１． 介護ネットワークシステムの概要
介護ネットワークシステムは、都道府県・国保連合会・市町村等に設置した共有サーバを仲介し、介護支援事業者及び地域包括支援センターと介護サービス事業者間の円滑な情報連携を実現する。これにより、各介護事業者間での情報の受け渡しのための印刷や仕分け、提出の手間、既存の介護ソフトへの入力作業といった煩雑な作業がなくなると共に、誤入力や入力忘れのない
正確な連携が可能となり、要介護者に適切な介護サービスが提供される。
図３−１に介護ネットワークシステムの全体の概要を示す。
なお、2 章にも記したとおり、介護ネットワークシステムは単独の保険者で利用するのではなく、複数の保険者で共用することが望ましいが、わかりやすさの観点から、本提案書では、単独の保険者の記述とする。

要介護者
要介護者
（要支援者）（要支援者）⑤介護サービスの提供

点線：人や紙の流れ実線：電子情報の流れ⑤介護サービスの提供

市町村
市町村

計画書

①計画書・提供票

介護支援事業者
介護支援事業者(地域包括支援センター)(地域包括支援センター)
連携ツール（予定）の取込③計画書・提供票（予定） の登録

介護サービス
介護サービス
事業者Ａ
事業者Ａ
介護
ソフト
提供票
レセプト

⑧提供票（実績）

都道府県・国保連合会
都道府県・国保連合会
市町村等
市町村等
共有
サーバ

からレセプト作成⑥提供票（実績）を登録④計画書・提供票（予定）の取込⑦提供票（実績）の登録⑨提供票（実績）⑥提供票（実績）

から給付管理票を作成

を登録

連携ツール

計画書
提供票
給付管理票

④計画書・提供票（予定/実績）の取込

ネットワーク

の作成

介護
ソフト

⑩計画書・提供票

連携ツール②計画書の提出

介護サービス
介護サービス
事業者Ｂ
事業者Ｂ
介護
ソフト
提供票
レセプト

⑧提供票（実績）
からレセプト作成

図３−１ 介護ネットワークシステム全体概要図

また、介護ネットワークシステムを利用した介護サービス提供の処理の流れを図３−１の番号と対応させた形で表３−１に示す。

18

表３−１ 介護ネットワークシステムを利用した処理の流れ
網掛けは介護ネットワークシステムの業務
＃
①
②
③
④
⑤
⑥
⑦
⑧
⑨
⑩

内容
介護支援事業者（地域包括支援センター）が、介護ソフトを用いて計画書・提供票（予定）を作成する。
介護支援事業者（地域包括支援センター）が、計画書を要介護者に送付する。
介護支援事業者（地域包括支援センター）が、計画書・提供票（予定）を共有サー
バに登録する。
介護サービス事業者が、計画書・提供票（予定）を共有サーバからダウンロードし、介護ソフトに取込む。
介護サービス事業者が、要介護者に介護サービスを提供する。
介護サービス事業者は、介護ソフトを用いて、提供票に実績を記入し、共有サー
バに登録する。
介護支援事業者（地域包括支援センター）は、共有サーバに登録された提供票（実績）をダウンロードし、介護ソフトに取込む。
介護サービス事業者は、提供票（実績）からレセプトを作成する。
介護支援事業者（地域包括支援センター）は、提供票（実績）から給付管理票を作成する。
市町村は、計画書・提供票（予定/実績）を共有サーバからダウンロードし、地域の介護サービスの実態の確認や、介護情報の分析に活用する。

３．２． 介護ネットワークシステムの仕様
介護ネットワークシステムの仕様を以下に示す。

（１） システム構成
介護ネットワークシステム構成図を図３−２に示す。都道府県・国保連合会・市町村等に設置した「介護情報共有サーバ」と、各介護事業者や市町村の端末をネットワークで接続する。
共有サーバ側は、Web ブラウザ通信用の「Web−AP」、連携ツールでの通信用の「連携ツール」があり、「業務ユニット」（後述）と「地域情報 PF 通信機能」で連携する。
介護事業者側は、新規で導入する「連携ツール」、または、「Web ブラウザ」を用いて共有サーバと接続する。

19

市町村

「介護情報共有サーバ」
業務ユニット
介護情報共有サーバ

DB

PF通信機能

既存端末

管理端末
連携ツール

Web-AP

緑 新規開発システム
青 既存ソフト

インターネット
介護支援事業者

介護
サービス事業者Ａ（地域包括支援センター）
WeB
ﾌﾞﾗｳｻﾞ

連携ツール

WeB
ﾌﾞﾗｳｻﾞ

連携ツール

介護
ソフト

既存端末

計画書
提供票
給付管理票

介護
サービス事業者Ｂ
WeB
ﾌﾞﾗｳｻﾞ

介護
ソフト

既存端末

提供票
介護レセプト

連携ツール
介護
ソフト

既存端末

提供票
介護レセプト

図３−２ 介護ネットワークシステム構成図（２） 介護ネットワークシステムの機能
介護ネットワークシステムを構成するユニットのうち、新規に開発する介護情報共有サーバ
業務ユニット及び連携ツール、介護事業者の既存ソフトと連携する連携ツールの機能を表３−２に示す。
まず、介護ネットワークシステムの中核となる「介護情報の共有サーバ」業務ユニットの機能としては、「利用者管理機能」、「居宅介護支援事業所連携機能」、「介護サービス事業所連携機能」、「地域包括支援センター連携機能」、「保守アラート機能」、「保険者参照・抽出機
能」を持つ。
「利用者管理機能」は、システムの各種機能が不正に利用されることを防ぐため、居宅介護支援事業者、介護サービス事業者、保険者等のシステム利用者の利用権限を管理するものである。なお、利用者の識別に当たっては、保険者番号や都道府県に登録されている介護事
業所番号（及びもしくは現在の国保連合会への請求支払業務で使用している事業所 ID）等の既存の ID を利用することを想定する。また、ID・パスワード等の管理に関しては、①事業所
ID・仮パスワードを郵送で事業所に通知、②事業所 ID・仮パスワードでログイン認証後にパスワードを変更、③変更後のパスワードはサーバ側で暗号化して管理という手順を想定する。
「保守アラート機能」は、データのバックアップや操作ログ等のシステム管理を行うと共に、利用者の操作忘れを防止するものであり、システムが適切に運用されるサポートを行う。
一方、各介護事業所の PC 上には、既存の「介護ソフト」とともに、新たに、「介護ソフト」と、「介護情報共有サーバ」とをプログラム連携するための「連携ツール」を導入する。この「連携ツール」は、介護データを XML 標準形式に相互変換する「介護データ変換機能」、及び、介護20

情報の共有サーバとの送受信を行う「介護情報送受信機能」から構成される。
「介護データ変換機能」により、各介護ソフトで異なるデータ項目となっている介護情報（CSV データ）を標準的なメッセージ（XML）に変換し、共有サーバでデータ共有やデータ交換を行えるようになる。
「介護情報送受信機能」は、以下の（3）に示すように SOAP に基づく方法を採用するが、介護業者と介護情報共有サーバ間の通信は、介護情報ネットワークの固有の特徴である介護業者が小規模事業体でサーバ設置ができず PC レベルでの接続となる点を考慮する必要がある。

21

表３−２ 「介護情報共有サーバ」業務ユニット機能の一覧
大分類

中分類

小分類

概要

ID・利用者権限、パスワ
利用者管理機能ードの登録・変更機能
利用者資格

ログイン画面で入力した ID・パスワードが、登録されてい確認機能

る情報と合致するかを確認する機能

サービス計画書

居宅支援事業所が共有サーバに送信した「計画書」を登

登録機能

録する機能

提供票（予定）居宅支援事業所が共有サー バに送信し た「 提供票（予事業所連携機能登録機能定）」を登録する機能

提供票（実績）居宅支援事業所が共有サーバに登録されている「提供票取得機能（実績）」をダウンロード用に取り出す機能

サービス計画書

介護サービス事業所が共有サーバに登録されている「計取得機能画書」をダウンロード用に取り出す機能

介護サービス

提供票（予定）介護サービス事業所が共有サーバに登録されている「提事業所連携機能

取得機能

供票（予定）」をダウンロード用に取り出す機能

提供票（実績）介護サービス事業所が共有サー バに送信した「提供票登録機能（実績）」を登録する機能

地域包括支援センタ
ー連携機能

市町村
参照・抽出機能保守・アラート機能

介護情報
送受信機能

サービス計画書

地域包括支援センターが共有サーバに送信した「計画書」

登録機能を登録する機能

サービス計画書
取得機能

地域包括支援センターが共有サーバに登録さ れている

提供票（予定）地域包括支援センターが共有サーバに送信した「提供票登録機能（予定）」を登録する機能「計画書」をダウンロード用に取り出す機能

提供票（予定）地域包括支援センターが共有サーバに登録さ れている取得機能「提供票（予定）」をダウンロード用に取り出す機能

提供票（実績）地域包括支援センターが共有サーバに登録さ れている取得機能「提供票（実績）」をダウンロード用に取り出す機能

サービス計画書

市町村が共有サーバに登録されている「計画書」の検索を参照・抽出機能行い、データの参照・抽出を行う機能

提供票（予定/実績）

市町村が共有サーバに登録されている「提供票（予定/実参照・抽出機能績）」の検索を行い、データの参照・抽出を行う機能

バックアップ機能登録されているデータのバックアップを行う機能
ログインした各システム利用者毎に操作のログ（操作内

証跡管理機能容・時刻）を管理する機能

登録・取込忘れシステムの利用者が「計画書」、「提供票」の登録・取込み

アラート機能忘れた際に利用者に知らせる機能「計画書」、「提供票」の XML データを共有サーバにアップ

アップロード機能

ロードされた情報を、受信し受信確認を返す機能

ダウンロード機能

連携ツールと介護情報共有サーバとの共有サーバより引き出された「計画書」、「提供票」の XML
データをダウンロードさせる機能「計画書」、「提供票」の XML データを共有サーバにアップ連携機能

ロードする機能

連携機能
XML データへの各介護事業所が介護ソフトからエ クスポー トし た「 計画

介護データ

変換機能

書」、「提供票」の CSV データを XML 形式に変換する機能

変換機能

CSV データへの共有サーバからダウンロードした「計画書」、「提供票」の事業者ｸﾗｲｱﾝﾄ（連携ツール）

事業者ｸﾗｲｱﾝﾄ（Web-AP）

ビス事業者、保険者）の ID・利用者権限、パスワードの新規登録、変更を管理する機能

居宅介護支援

介護情報共有サーバ（業務ユニット）

介護情報共有サーバ（連携ユニット）

各システム利用者（居宅介護支援事業者、居宅介護サー

変換機能

XML データを CSV 形式に変換する機能

アップロードクライアント「計画書」、「提供票」の XML データを共有サーバにアップ

介護情報

機能

ロードする機能

送受信機能

ダウンロードクライアント

共有サーバから「計画書」、「提供票」の XML データをダウ機能

ンロードする機能

データ登録と参照

Web 画面から標準データ項目のエントリと参照する機能

Web ﾌﾞﾗｳｻﾞ用
サービス

22

図３−３に、「介護情報共有サーバ」業務ユニットのシステム構成例を示す。
なお、本構成では、共有サーバは複数のサーバ構成とし、PT 通信機能を設けているが、処理量が少ない場合は、ＰＦ通信機能を使わず、１台のサーバ内に、すべての機能を実現する
方法でもよい。

介 護事 業者クライ アン ト
提供票
介 護レ セプ ト

介護 情報 共有サ ーバ
介護
ソフト

We b
ブ ラウザ

介護
ソフト

介 護情報

送受 信機能IN BO X

送 受信機 能業 務ユ ニット

保守・ アラート 機能

PF通信機 能介護 情報

連 携ツ ール介 護情 報共有 サー バ
PF通 信機能

連携ツ ール（サ ーバ側 ）介 護事 業者クライア ント

提 供票
介 護レセ プ ト

管理 端末

Web‑AP（Webﾌﾞﾗｳｻﾞ用）

利 用者管 理機能
介護 支援事 業所 連携機 能
介護 サービ ス事 業所 連携機 能

介護
情報
共通
DB

市町 村参 照・抽出 機能

共 有サ ーバ
連 携機 能CSV-XM L
変換 機能

図３−３ 「介護情報共有サーバ」業務ユニットのシステム構成例（３）通信方式「介護ネットワークシステム」の通信方式としては、以下表３−３に示す APPLIC 技術専門委
員会が検討している「地域情報プラットフォーム仕様」のプラットフォーム通信機能（ＰＦ通信機
能）に準拠した仕様とする。
表３−３ プラットフォーム通信機能
ネットワークメッセージ交換プロトコル
メッセージ形式とその定義

インターネット
TCP/IP、 SOAP V1.1 over HTTP V1.1
XML V1.0、 W3C XML Schema V1.023

なお、物理的なネットワークとしては、介護ネットワークシステムでは、インターネットに接続していない介護事業者も存在するため、導入期では、インターネット限定ではなく、国保連合会への請求業務で使用している INS64 回線での運用も検討する。

（４）メッセージ定義「介護ネットワークシステム」のメッセージは、保健医療福祉情報システム工業会（以下、JAHIS と表記する）が介護事業者間の情報連携を目的に、検討・作成を行った「介護標準メッセージ」（XML Schema）を採用することとする。「介護標準メッセージ」（XML Schema）は、現行の介護保険制度で採用されている帳票を基に作成されている。
以下に、「介護標準メッセージ」で規定されている情報と介護保険制度で活用されている帳票の対応を表３−４に、規定している XML Schema のサンプルを図３−４に示す。なお、「介護標準メッセージ」で規定している XML Schema 及びデータ定義（タグセット）構造は、別添資料として、本基本提案書の末尾に示す。
表３−４ 介護標準メッセージの種類と対象帳票
網掛け：「介護ネットワークシステム」で使用する情報＃
１

介護標準メッセージの種類
介護保険証情報２

居宅サービス計画書情報

３

サービス提供票情報

４

予防サービス計画書情報

５

予防サービス提供票情報

対象帳票・介護保険証書・居宅サービス計画書(1)・居宅サービス計画書(2)・週間サービス計画表
・サービス提供票・サービス提供票別表・介護予防サービス支援計画表
・週間サービス計画表
・予防サービス提供票
・予防サービス提供票別表【出典：JAHIS「介護標準メッセージ（2007 年 3 月改定)」】<?xml version="1.0" encoding="Shift_JIS"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"><xsd:element name="Address"><xsd:complexType><xsd:attribute name="city" type="xsd:string" use="optional"/><xsd:attribute name="state" type="xsd:string" use="optional"/><xsd:attribute name="strt" type="xsd:string" use="optional"/><xsd:attribute name="zip" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Agreement"><xsd:complexType/></xsd:element><xsd:element name="Assesment"><xsd:complexType/></xsd:element><xsd:element name="AnotherDivPayMaxMng"><xsd:complexType/></xsd:element><xsd:element name="AnyTime"><xsd:complexType><xsd:attribute name="Add" type="xsd:string" use="required"/>XML Sｃhema例【出典：JAHIS「介護標準メッセージ（2007 年 3 月改定)」】
図３−４ XML Schema サンプル24

（５） プロトコル
介護情報共有サーバのサーバサイト内と、介護業者等のクライアント側と介護情報共有サーバサイトにおけるプロトコルは、SOAP に基づく方法を採用するが、介護情報ネットワークの固有の特徴である、介護業者が小規模事業体でサーバ設置ができず、PC レベルでの接続となる点を考慮する必要があるため、PC 側には SOAP のクライアントとして、XML 標準メッセー
ジをサーバへアップロードやダウンロードする方式とする必要がある。
要件を満たす標準規格を調査した結果、日本の流通業界が策定した「JX 手順（注３）」が候補仕様として有力である。「JX 手順」は、インターネットに対応した EDI メッセージのクライアン
トとサーバでデータ交換する SOAP ベースの標準規格で、ベンダで製品化されて大手小売や卸間で実用が始まっている規格である。XML メッセージを規定することで、任意の XML をサー
バの INBOX との間にアップロード、ダウンロードできる仕様である。
（注３）：JX 手順
ＪＸ手順は、インターネットに代表される TCP/IP 上で企業間 EDI を行う際のメッセージ交換
手順について、国際標準仕様(SOAP-RPC)を基に(財)流通システム開発センターが制定したガイドラインである。
SOAP-RPC（SOAP-Remote Procedure Call）は、B2B サーバの常時運用が困難な中小企業向けのプロトコルである。SOAP-RPC はプル型で、必要な時に任意のタイミングで、クライアントから起動して、センターサーバからデータを取得することができる。（流通業界は小規模事業者が多く、サーバ間のプロトコルでなく、プル型の C/S 型の連携手順が求められていた）。任意のタイミングでクライアントを立ち上げ、センターからデータを引き出すこと、また、自分の意思で、データをサーバへアップロードが出来る。ただし、プッシュ型の送信ができないた
め、新着到着等を自動判定できない欠点がある。時間を決めた定期アクセスが必要である。
本手順は、すでに流通業界において標準化され、クライアント側は、安価な製品が販売されている。
クライアントサーバ

クライアント

PutDocument

GetDocument

アック MSG

取得 MSG

サーバ

ConfirmDocument

アック MSG(a)登録プロトコル(b)取得プロトコル

図３−５ JX 手順のプロトコル

今後、ＪＸ手順が本システムの通信手順として最適なのか、継続検討を行うとともに 、JX 手順を採用する場合は、「介護ネットワークシステム」としての要件に合致するための使い方ガイド（プロファイル）の整備や、「JX 手順」の作成元の(財)流通システム開発センタとの仕様の使用に関する調整を行うことが必要となる。

25

（６） セキュリティ対策
地域情報プラットフォーム仕様においてセキュリティに関する考え方は、対象システムを利用する業界のセキュリティ対策基準に準ずる、となっている。
介護ネットワークシステムを利用する介護関係事業者に関する厚生労働省のガイドライン
及び関連情報としては下表の 4 つがある（表３−５）。
表３−５ 介護関係事業者に関する厚生労働省のガイドライン等＃

ガイドライン名

時期

対象範囲・概要
個人情報保護法に基づく医療機関・介護事業所における個人データに対する

医療・介護関係事業①

者における個人情報の適正な取扱いのた

安全管理措置として、下記を規定している。

H16．12めのガイドライン・物理的安全管理措置 ： 入退室管理、盗難予防ほか
・技術的安全管理措置 ： ID・PW 認証、アクセス管理、アクセス記録ほか
・データ保存： 長期保存、検索インデックスの整備
・データ廃棄・消去
医療機関の個人情報を扱うシステムにおけるセキュリティ・IT 障害への対策。
システムにおける、外部との個人情報を含む医療情報をオープンなネットワ

医療情報システムの② 安全管理に関するガ H19．3
イドライン （第 2 版）

ークを用いて交換する場合の安全管理として、下記を規定している。
・「盗聴」の危険性の対応 ： ＳＳＬ-ＶＰＮ、ＩＰＳｅｃほか
・「改ざん」の危険性の対応 ： ＳＳＬ-ＶＰＮ、電子署名ほか
・「なりすまし」の危険性の対応 ： 公開鍵方式認証ほか
医療機関･薬局、審査支払機関、保険者などの電子的なレセプトの取扱いに関するセキュリティ対策。レセプトデータを扱う際の技術的セキュリティとして、下記を例示している。

レセプトのオンライン③

請求 に係る セキュリ
ティに関する・データの機密性の確保 ： OS･DBMS によるアクセス制御、暗号化による

H19．4

ガイドライン

アクセス制御・伝送相手の正当性の確保： 電子証明書による認証
・伝送事実の正当性の確保： 電子署名付与データの送付、受領確認返信、送信・受信ログの保管 ほか・システムの機密性の確保： ユーザ ID・PW 認証、OS･DBMS によるアクセ
ス制御ほか

④

「レ セプト のオ ンライ

上記②、③両ガイドラインの整合性を取るために、③ガイドラインの一部改定

ン請 求に係 るセキュを 2008 年 5 月請求分から適用する旨の連絡で、下記の内容の改正事務連絡

リティに関するガイド
ライン」等の改定に向H19．12が厚生労働省よりなされている。
・「レセプトのオンライン請求に係るセキュリティに関するガイドライン」に例

けた検討状況につい示されている技術的セキュリティ対策にＩＰsec と IKE （Internet KeyてExchange）の組合せによる接続方式を追加する

26

一方、介護ネットワークシステムと同様に介護事業所がインタ−ネットを利用してデータ交換するシステムとして「障害者自立支援システム」があり、本システムは、「レセプトのオンライン請求に係るセキュリティに関するガイドライン」に準拠し、下記のセキュリティ対策を行っている。
（a）「盗聴」の危険性の対応： ＳＳＬ−ＶＰＮ + 公開鍵暗号化（b）「改ざん」の危険性の対応： ＳＳＬ−ＶＰＮ + 電子署名付与（c）「なりすまし」の危険性の対応： 利用者 ID・パスワード認証 + 公開鍵方式認証

これらのガイドライン及び類似事例を考慮しつつ、具体的なセキュリティ対策を検討するにあたっては、介護ネットワークシステムの中身及び利用する環境を考慮する必要がある。介護ネットワークシステムの位置づけを以下に整理する。
・複数の保険者で利用されるのが望ましく、設置場所としては、都道府県、国保連合会等が考えられる
・データ入出力端末は介護支援・サービス事業所に設置され、パソコン操作に不慣れなケ
アマネージャー、ヘルパーが操作する・扱うデータはサービス計画書とサービス提供票であり、請求情報は扱わない
このように、介護ネットワークシステムは、あまりに高度なセキュリティ対策を施すと、費用がかさみ、また操作・運用が十分にできないことが考えられる。
そこで、①市町村への導入を前提としたシステム化当初は、リスクの受容範囲を見定めた
上で、利用者の操作・運用を考慮したセキュリティ対策とする、②システムの規模、扱いデー
タの増加・変更に伴いセキュリティレベル、対策内容を見直すという方針の下、「レセプトのオ
ンライン請求に係るセキュリティに関するガイドライン」ではなく、「医療情報システムの安全管理に関するガイドライン （第 2 版）」及び「医療・介護関係事業者における個人情報の適正な取扱いのためのガイドライン」に準拠し、下記のセキュリティ対策を行うのが適当と考える。
（a）「盗聴」の危険性の対応： ＳＳＬ−ＶＰＮ（b）「改ざん」の危険性の対応： ＳＳＬ−ＶＰＮ（ｃ）「なりすまし」の危険性の対応： 利用者 ID・パスワード認証

上記対応にあたっては、利用者毎のアクセス制限及び権限管理を厳密に行うことが重要である。また、自治体ごとに定めるセキュリティポリシーへの対応が求められる場合があることを考慮しておく必要がある。さらに、システム的には将来のセキュリティレベル向上の際に改修が少なくて済むように拡張性を持たせた設計を行う必要がある。

27

なお、セキュリティ対策に関しては、技術の進歩や環境の変化に応じて、関連ガイドライン・
類似システムも逐次変化している。今後も関連ガイドラインの改正内容の把握及び関係機
関・利用者のご意見を頂きセキュリティレベル、対策を見直していく必要がある。

３．３． コストの検討「介護ネットワークシステム」のあり方や費用負担の考え方の検討を行うため、さらには、市町村等が介護ネットワークシステムを導入する際の参考資料としても、コストの検討は必要である。
しかし、介護ネットワークシステムのコスト検討の前提となる仕様の詳細については、前述した
ように継続検討の部分を多く含んでおり、いまだ確定していない。また、市町村だけでなく事業者も含めてのシステムとなるため、どの程度の事業者が参画できるか（例外処理の扱い方）、どの程度の市町村が共用するかにより、コスト検討の前提となるシステム形態そのものが大きく異なる。
さらに、システムの費用負担の考え方そのものも、十分にコンセンサスが取れていない状況である。
そこで、今回は、コストのベースとなるサーバシステムのハード・ミドルのモデル構成の検討と、介護事業者の介護ソフトの一部をカスタマイズするに当たっての開発ベンダの対応の可否の分析を行った。なお、今回の検討は、かなり大雑把かつ幅をもったものであり、また、実際のシステム構築の際に考慮すべき市町村や事業者の個別の事情はまったく考慮していない点に十分留意されたい。

（１） サーバシステムのハード・ミドルのモデル構成検討
共有サーバシステムのハード、ミドルの費用を検討する。
検討にあたっては、サーバシステムは、iDC 等に設置するものとして、ネットワーク機器等
は構成に含まないものとする。また、市町村のインターネットへの接続は、各市町村のセキュ
リティポリシー等を考慮する必要があるため、本検討では対象外とする等の大前提をおいた。

①前提条件
システムのモデル構成を検討するにあたっての前提条件を表３−６に設定した。具体的には、人口規模を 20 万人とし、そこから介護保険受給者の人数を推計し、備考で記した仮定をおいた上で、データ量とトランザクション等の前提条件を推計した。
なお、表３−６の基礎数値は、全て仮説の上での参考数値であり、仮に同じ人口規模の自治体でシステム構築を検討したとしても、同じ前提となるものではない。

28

表３−６
＃
１

システムのモデル構成における前提条件

項目①人口規模（②高齢者数）

前提条件

備考

①200,000 人（②50,000 人）②高齢化率を 25%と仮定①高齢者の内 20％が利用すると仮定

２①介護保険受給者数①10,000 人（②6,000 人）②介護保険受給者の内、6 割が居宅介護サー（②居宅介護サービス利用者）
ビスを利用していると仮定

３

４①支援事業所数＝60①１事業所あたり 100 人を担当していると仮定②サービス事業所数＝200②１事業所あたり 30 人を担当していると仮定

1 件あたりデータ量

計画書：13KB

JAHIS 標準を基にサンプルを作成して算出（XML ファイル）

提供票：10KB（参考値）

接続事業所数①自治体内で年間に 6,000 枚の計画書が作成①支援事業所⇒サーバ＝500 件
計画書されると仮定（更新は全て 1 年と仮定）②サーバ⇒サービス事業所＝2,500 件/月②5 つのサービス事業所に提出すると仮定

月あたりのデータ

５①要介護者 1 人あたり 1 データとする
送受信件数（自治体全体）提供票①支援事業所⇒サーバ＝6,000 件/月（予定）②サーバ⇒サービス事業所＝30,000 件/月②提供票 1 ファイルあたり 5 つのサービス事業所がかかわると仮定（6,000×5＝30,000）
提供票①サービス事業所⇒サーバ＝30,000 件/月

提供票１ファイルあたりに 5 つのサービス事業（実績）②サーバ⇒サービス事業所＝30,000 件/月

所が関わると仮定（6,000×5＝30,000）①１支援事業所≒8 件/月（送信）①500 件/60 事業所≒8 件②１サービス事業所≒13 件/月（受信）②2,500 件/200 事業所≒13 件

提供票①1 支援事業所＝100 件/月（送信）①6,000 件/60 事業所＝100 件（予定）②1 サービス事業所＝150 件/月（受信）②30,000 件/200 事業所＝150 件

提供票①１支援事業所≒150 件/月（送信）①30,000 件/200 事業所＝150 件（実績）②1 支援事業所≒500 件/月（受信）②30,000 件/60 事業所 ＝500 件

計画書
月あたりのデータ

６

送受信件数（1 事業所あたり）

７

・月途中の計画書や提供票（予定）の変更に関しては、考慮しない。
備考・システムの 2 重化は考慮していない。

29

②ハード・ミドルのモデル構成
上記の前提条件を基に「介護ネットワークシステム」の共有サーバシステムのモデル構成を検討した。前述の通り、サーバシステムは iDC 等に設置するものとして、ネットワーク
機器等は構成に含まないものとしている。また、市町村のインターネットへの接続は、各市町村のセキュリティポリシー等を考慮する必要があるため、検討の対象外としている。さらに市町村や介護事業所が使用するクライアント側の構成は対象外としている。
表３−７にハードのモデル構成を示す。
表３−７ ハードのモデル構成例
＃

区分

台数

スペック
2CPU モデル Windows server(R)2003

１

Web/AP サーバ

1

CPU：Xeon(R) 5160(3GHz)
メモリ：2GBHDD：アレイタイプ 73GB×2(RAID-1)内臓ディスク
2CPU モデル Windows server(R)2003

２

DB サーバ

1

CPU：Xeon(R) 5160(3GHz)
メモリ：2GBHDD：アレイタイプ 73GB×2(RAID-1)内臓ディスク

３

UPS

2

無停電電源装置※各サーバに使用

表３−７のハードに具備すべきミドルウエアのモデル構成を表３−８に示す。なお、実際のシステム構築においては、アプリケーションプログラムの開発方法や DB サーバでのデータの保持方法（データ形式等）を考慮して構成を再度検討する必要がある。ちなみに、本
モデル構成では、XML データベースを前提としたミドルウエアの構成としている。
表３−８ 各サーバに備えるミドルウエアのモデル構成例
＃

区分

１

Web/AP サーバ

２

DB サーバミドルウエアWeb アプリケーションサーバ、通信制御、バックアップ、
簡易オペレーションマネージャなど
XML データベース、通信制御、バックアップ、
オペレーションマネージャなど

30

（２） 介護ソフトのカスタマイズ対応の検討「介護ネットワークシステム」では前述の通り、介護事業者の PC 側の対応も必要となる。
現在、全国のほとんどの介護事業者では、介護ソフトを既に導入している。介護ソフトの開発ベンダは約 50 社程度と想定され、大手数社は存在するものの、介護事業者は自身の判断で介護ソフトを選択し購入しており、1 社の介護ソフトが独占している地域は、まずない。
そこで、介護ネットワークシステムでは、既存の介護ソフトをできる限り利用する方針とし、連携部分のみを新規に連携ツールとして開発し、既存の介護ソフトの一部をカスタマイズする（連携ツールに計画書や提供票といった必要データを吐き出す）方式とした。この吐き出す工数がどの程度であるか、また、吐き出すデータの形式はどのようなものがいいかを検討するため（XML か、CSV か）、介護ソフトの開発ベンダにアンケートを実施した。
以下、実施したアンケートの概要と今回のアンケートの集計結果から見える考察を記載する。なお、アンケート内容とアンケート結果は、巻末に別添資料として添付する① アンケートの概要
今回、介護ネットワークサービスプロジェクトでは、全国の介護ソフトベンダにアンケートを実施し、「介護ネットワークシステム」に係る介護ソフトの対応費用を調査した。アンケー
トの実施概要を表３−９に示す。
表３−９ アンケート実施概要
項目

アンケート実施日程

実施内容

平成 19 年 12 月 14 日から平成 20 年 1 月 24 日の回答内容を集計
独立行政法人福祉医療機構サイト「WAMNET」に掲載されている介護保険業務管理ソフトベンダ 57 社を対象に実施

アンケート先の選定＜参考＞「WAMNET」 介護業務ソフト特集
URL： http://www.wam.jp/soft/index.html

送付・回収方法
回答数

送付・回収共に電子メールを利用
20 社/57 社（回収率 35.1％）31

② アンケートの考察
アンケートをベースに、既存の介護ソフトが計画書や提供票を吐き出す工数がどの程度であるか（既にインポート、エクスポート機能をもっているか）、また、吐き出すデータの形
式はどのようなものがいいか（XML か、CSV か）を考察した。なお、アンケート結果の見積
もり金額は、調査期間が短期間であり、具体的な見積もりでないことを考えると、あくまで絶対値としてではなく、軽重の参考数値として扱うのが適当であると考える。

（ａ）計画書・提供票の CSV データのインポート/エクスポート機能「介護給付帳票のうち、居宅サービス計画書第 1 表〜第 3 表、提供票・別表の CSV デー
タのインポート/エクスポート機能を具備しているかどうか」の質問に対しては、「エクスポー
ト機能のみ具備している」、「インポート機能のみ具備している」がそれぞれ１社（5％）だけという結果となった。60％のベンダが「具備していない」、30％のベンダが「独自バイナリ形
式であれば具備している」等の条件付きである結果となった（図３−６）。

インポート/エクスポート機能の具備
5% 5%
30%
エクスポート機能のみ具備している
インポート機能のみ具備している
当該機能を具備して
いない
その他

60%

図３−６

インポート/エクスポート機能の具備32

（ｂ）予防帳票の CSV データのインポート/エクスポート機能（介護予防サービス・支援計画書 厚生労働省様式）「予防給付帳票のうち、介護予防サービス・支援計画書 厚生労働省様式の CSV データのインポート/エクスポート機能を具備しているかどうか」の質問に対しては、「インポート/
エクスポート機能の両方を具備」が 10％、「エクスポート機能のみ具備」が 5％、「インポート機能のみ具備」が５％という結果となった（図３−７）。

予防帳票のインポート/エクスポート機能の具備
10%

15%

5%
5%

インポート/エクスポー
ト両方具備している
エクスポート機能のみ具備している
インポート機能のみ具備している
当該機能を具備してい
ない
その他

65%

図３−７ 予防帳票のインポート/エクスポート機能の具備（ｃ）JAHIS の「介護標準メッセージ」
JAHIS の「介護標準メッセージ」に関する設問では、50％のベンダが名前は知っているとの回答であり、「介護標準メッセージ」に準拠した機能を具備しているベンダは１社もなかった（図３−８）。
なお、参考情報として、「介護標準メッセージに準拠した計画書・提供票等の XML データのインポート/エクスポート機能を具備するための費用」という質問も行っているが、これに対しては、1,000 万円以上が 21％、700 万円以上 1,000 万円未満が 11％、100 万円以上
400 万円未満が 36％、平均で約 565 万円となっている。
一方、「CSV 形式での計画書・提供票のインポート/エクスポート機能を具備するための費用」に関しては、1,000 万円以上が 5％、400 万円以上 700 万円未満が 16％、100 万円
以上 400 万円未満が 68％、100 万円未満が 11％、平均で約 320 万円となっており、XMLにするだけで、約倍の工数がかかることになる。

33

JAHISの認知度

50%

50%

名前は知っている
知らない

図３−８ JAHIS の認知度
以上、アンケートの結果から、2／3 のベンダがインポート・エクスポート機能を具備していな
い、1／3 のベンダが独自バイナリ形式で具備しているということがわかった。また、JAHIS の「介護標準メッセージ」への対応は、CSV データへの吐き出しのおよそ倍の工数が要することがわかった。
つまり、インポート・エクスポートするデータの形式は、XML ではなく、CSV としたほうが大幅な開発費圧縮につながるため、連携ツールに XML への変換機能を搭載したほうがよい（本基本提案書の仕様は連携ツールに変換機能を持たせている）。
さらに、単独の介護事業者であれ、介護ソフトベンダの提供している全ての介護事業者であれ、同じ開発コストがかかることから、本システムの導入は、できる限り多くの地域でいっせいに導入するのが、社会全体のコストの観点からもふさわしいと言える。

34

４. 介護ネットワークシステムの効果（１） 問題点に対する効果「介護ネットワークシステム」を構築する事で解決する効果を問題点ごとに示す。
① 市町村における介護情報見える化
都道府県・国保連合会・市町村等に設置した共有サーバに蓄積された介護情報（計画書・提供票(予定/実績)）の情報を市町村が参照・抽出する。これにより、市町村が地域の介護状況を正確かつ効率的に把握できるようになり、介護事業の経営者として、適切な介護サービスの提供が実施できているかの確認、適切な介護サービス提供に向けた根拠（データ）に基づいた介護事業の経営を行うことが可能となる（図４−１）。

問題
題点
点
問

現状の市町村の介護情報の把握状況
・市町村が、介護サービスの提供状況を把握できていない・市町村が、介護サービスの提供状況を把握できていない
・計画書の分析を実施するマンパワーがない
・計画書の分析を実施するマンパワーがない
介護支援事業者
介護支援事業者(地域包括支援センター)(地域包括支援センター)（手渡し、ＦＡＸ等）

介護サービス事業者
介護サービス事業者

計画書
提供票（予定）提供票(実績)（手渡し、ＦＡＸ等）
計画書

提出されていない場合が多い。

サービスの提供

市町村
市町村

要介護者
要介護者

地域の介護情報が把握で
きない。

解決
決策
策
解

・市町村が計画書・提供票（予定/実績）を電子データ入手できるようにする
・市町村が計画書・提供票（予定/実績）を電子データ入手できるようにする

介護ネットワークシステム実現後の将来像
介護支援事業者
介護支援事業者(地域包括支援センター)(地域包括支援センター)

介護サービス事業者
介護サービス事業者

計画書・提供票（予定）の登録計画書・提供票の取込

共有サーバ

提供票（実績）
の取込

市町村
市町村

提供票(実績)の登録

サービスの提供
要介護者
要介護者（要支援者）（要支援者）

計画書
提供票（実績）効果
果効・地域に提供している介護サービスの状況を把握することで、適切な介護サービスが提供できているかの確認を・地域に提供している介護サービスの状況を把握することで、適切な介護サービスが提供できているかの確認を行えるようになる。
行えるようになる。
・根拠（データ）に基づいた介護事業の設計・運営を行うことができる。
・根拠（データ）に基づいた介護事業の設計・運営を行うことができる。

図４−１ 市町村における介護情報の把握の現状と将来像35つまり、「介護ネットワークシステム」を利用することで、これまで市町村で保有していた
介護情報（認定情報、給付実績、3 年に 1 度の介護保険事業計画策定に向けた調査）に加え、計画書・提供票を入手でき、要介護者の介護サービスに関わる一連の情報全てを、タ
イムリーに把握することが可能となる（表４−１）。これにより、個別の帳票の内容のチェッ
クだけでなく、例えば、要介護者の中期の介護計画である計画書と月毎のサービス内容が記載されている提供票を比較することで、「介護計画に沿ったサービスの提供がなされているのか」等の帳票間のチェックを行うこともできる。
表４―１ 市町村が把握する情報の比較＃
1

要介護者に関わる介護情報例
認定情報（アセスメント・主治医意見書等）

現在市町村で把握

介護ネットでしている情報新たに把握できる情報

○

−

2

計画書

−

○

3

提供票（予定）−○4

提供票（実績）−○5給付実績（国保連合会から送付）

○

−

○

−

3 年に 1 度、介護保険事業計画策定時に6実施している介護保険利用者に対するア
ンケート等の調査

36

② 介護事業者間のスムーズな情報連携の実現
図４−２に「介護ネットワークシステム」を構築する事で解決する介護事業者間の情報連携の効果を示す。まず、「計画書・提供票（予定/実績）のデータを一括して登録できるようになり、印刷・仕分け・提出の手間が削減される」、「電子データで受け取ることで、介護ソフトへの入力の手間を削減できる」、｢電子データで計画書・提供票(予定/実績)の受け渡しを行うため、正確な情報伝達ができる｣等が考えられる。また、削減した時間を計画書のセルフチェックや、要介護者とのコミュニケーションに当てることで要介護者に充実した介護サービスを提供できる。
現状の介護事業者間の情報の受け渡し
問題
題点
点
問

・計画書・提供票の提出先である介護サービス事業者や提供票（実績）の送付先である介護支援事業者と地域・計画書・提供票の提出先である介護サービス事業者や提供票（実績）の送付先である介護支援事業者と地域包括支援センターがそれぞれ複数存在し、提出元で仕分け作業が発生している包括支援センターがそれぞれ複数存在し、提出元で仕分け作業が発生している・介護事業者は、それぞれ介護ソフトを用いて、計画書・提供票（予定/実績）を電子的に作成しているにも関・介護事業者は、それぞれ介護ソフトを用いて、計画書・提供票（予定/実績）を電子的に作成しているにも関わらず、他の介護事業者との受け渡しでは、いったん紙に印刷して提出しているため、手間がかかっている
わらず、他の介護事業者との受け渡しでは、いったん紙に印刷して提出しているため、手間がかかっている
・介護事業者は、計画書・提供票（予定/実績）を受け取る場合に、それらの内容を介護ソフトに入力する手・介護事業者は、計画書・提供票（予定/実績）を受け取る場合に、それらの内容を介護ソフトに入力する手間がかかっている
間がかかっている
介護支援事業者
介護支援事業者(地域包括支援センター)(地域包括支援センター)

介護サービス事業者
介護サービス事業者Ａ
Ａ

計画書

ﾃﾞｰﾀ入力再入力

提供票（予定）

計画作成

印刷
実績報告

提供票(実績)印刷

実績報告（手渡し、FAX等）
介護サービス事業者
介護サービス事業者Ｂ
Ｂ

計画書

仕分け

ﾃﾞｰﾀ入力再入力

提供票（予定）印刷

送付
提供票(実績)

実績報告

実績報告

（手渡し、FAX等）

修正・再送

介護サービス事業者
介護サービス事業者Ｃ
Ｃ
計画書

実績確認

ﾃﾞｰﾀ入力再入力

提供票（予定）

印刷

実績入力

実績報告

実績報告

提供票(実績)（手渡し、FAX等）

解決
決策
策
解

・介護事業者が各種介護帳票を電子データで受け渡しできるようにする・介護事業者が各種介護帳票を電子データで受け渡しできるようにする

介護ネットワークシステム実現後の将来像
介護サービス事業者 Ａ
介護サービス事業者 Ａ

介護支援事業者
介護支援事業者(地域包括支援センター)(地域包括支援センター)

計画書・提供票
の取込

計画作成

実績登録

計画書・提供票（予定）の登録

修正・再登録取込

提供票(実績)
の取込

共有サーバ

登録

取込 再入力提供票(実績)の登録計画書・提供票の取込

実績報告

介護サービス事業者 Ｂ
介護サービス事業者 Ｂ

取込 再入力提供票(実績)
の登録

実績登録

実績報告

計画書・提供票の取込

実績確認

介護サービス事業者 Ｃ
介護サービス事業者 Ｃ
提供票(実績)の登録

取込 再入力
実績登録

実績報告

効果
果
効

・計画書・提供票（予定/実績）のデータを一括して登録できるようになり、印刷・仕分け・提出の手間が削減で・計画書・提供票（予定/実績）のデータを一括して登録できるようになり、印刷・仕分け・提出の手間が削減できる
きる
・電子データで受け取ることで、介護ソフトへの入力の手間を削減できる
・電子データで受け取ることで、介護ソフトへの入力の手間を削減できる
・電子データで計画書・提供票・提供票(実績)の受け渡しを行うため、正確な情報伝達ができる・電子データで計画書・提供票・提供票(実績)の受け渡しを行うため、正確な情報伝達ができる

図４−２ 介護事業者間の情報連携の現状と将来像

37

③ 関与者別の効果「介護ネットワークシステム」の効果のまとめとして介護サービスに関わるプレイヤー毎の効果を表４−２に示す。
表４−２ 介護ネットワークシステム導入による効果
＃

プレイヤー

介護ネットワークシステム導入よる効果①計画書・提供票の情報をリアルタイムに把握することができ、変更等の履歴も過去に遡って確認することが出来る。

１

市町村②既存の「介護給付適正化システム」の提供情報と併せて確認することで、地域の介護情報をより確実に把握することが可能となり、根拠に基づいた介護事業の経営を実施できる。
①計画書・提供票の印刷・仕分け・配布に関わる業務を効率化することが出来る。
②電子データで受け取ることで、介護ソフトへの入力の手間を削減出来る。

２

居宅介護支援事業者（但し、介護ソフト側の対応が必要）③電子データで受け渡しを行うため、正確な情報伝達が可能となる。
④業務効率化により削減した時間を計画書のセルフチェックや、担当している要介
護者の訪問等を充実することが出来る。
①計画書・提供票の印刷・仕分け・配布に関わる業務を効率化することが出来る。
②電子データで受け取ることで、介護ソフトへの入力の手間を削減出来る。

３

地域包括支援センター（但し、介護ソフト側の対応が必要）③計画書・提供票の作成を介護予防支援事業所に依頼する場合の帳票の受け渡しを電子データで効率的に行うことが出来る。
（地域包括支援センターの業務としては、共有サーバに登録された情報の確認がメインとなる）①提供票の印刷・仕分け・配布に関わる業務を効率化することが出来る。

４

介護サービス事業者②電子データで受け取ることで、介護ソフトへの入力の手間を削減出来る。
（但し、介護ソフト側の対応が必要）③電子データで受け渡しを行うため、正確な情報伝達が可能となる。
①正確な情報伝達に基づいたサービスを享受することが出来る。

５

要介護者

②市町村が共有サーバに蓄積された介護情報を参照できることから、煩雑なサービスに対して「抑止力」が働き、適切なサービスを享受できるようになる。

38

５. 今後の課題
介護ネットワークシステムの次年度に向けた検討課題と将来の方向性を示す。

５．１． 次年度の検討課題
次年度に向けた検討課題としては、以下に示すように、今年度までに机上にて検討した内容を、実証実験等を行うことにより詳細化・具体化し、仕様書としてまとめていくことと、集約した情報を
介護及び高齢者福祉にどのように反映させるかの検討がある。
（１） 実証実験による詳細仕様の検討
３章でも継続検討とした機能の詳細、プロトコル、セキュリティ等は、実証実験等を通して、詳細を検討していく必要がある。

（２） 実証実験による効果の具体化
４章の効果の具体例を、実証実験等を通して、（できれば複数の地域で）確認していく必要がある。

（３） 厚生労働省と連携したスキーム整理
国保連合会の給付適正化事業との役割分担やシステムの設置場所等スキームにかかわる事項を、厚生労働省とも連携し、検討していくことが重要である。
（４） 自治体等への普及活動（コンセンサス）
実証実験等の具体的なシステムを見てもらいながら、また、（２）の効果の検証と連動しつ
つ、自治体等への普及を図っていく。

（５） 介護事業経営に向けた介護等高齢者情報の具体的活用方法の検討
市町村による介護事業経営に向けて、①今回市町村に集約した介護情報の具体的活用方
法や②さらに追加で収集すると有益な高齢者情報とその活用方法の調査・分析を行うことが重要である。

39

５．２． 将来の方向性
介護ネットワークシステムの将来の方向性としては、共有する情報の拡張、提供する人の拡張、介護から予防へのサービスの拡張の３つがある。以下、各方向性の概要を示す。

（１） 要介護者の経過記録等の共有① 現状の問題点
介護サービス事業者は、提供票の記載内容により、同一の要介護者に対して、他の介護サービス事業者が提供しているサービス内容は把握しているものの、サービス提供時の要介護者の状況等までは、把握していない。
また、居宅介護支援事業者が定期的に要介護者を訪問し、確認した情報を要介護者にサービスを提供する介護サービス事業者に周知しているものの、口頭やメモでの伝達に留まっており、正確な情報共有が出来ていない。
② 解決の方向性「介護ネットワークシステム」で構築した情報基盤を生かし、計画書・提供票（予定/実績）の介護帳票情報だけでなく、サービス提供時における要介護者の状態や留意点等を共有する。
医療機関とも連携し、主治医意見書の共有や主治医からのアドバイス情報等も共有する。要介護者の日々の状況を電子データで蓄積することで、要介護者の状況を時系列で辿ることが可能となり、居宅介護支援事業者が計画書の更新時や提供票の作成時に介護サービスの内容を検討する上でも参考とすることが可能となり、より適切な介護サービスを提供できる。
また、市町村がより、現実に沿った地域の介護状況を把握することが可能となり、介護事業の経営に反映することができるようになる。

（２） 要介護者・家族に対するサービスの拡充① 現状の問題点
要介護者及びその家族は、介護事業者が保険者に請求する報酬請求情報をチェックすることが出来ない。例えば、要介護者に提供された介護サービスとは異なる給付費が保険者に対して請求されていても、請求内容を確認することができない。
また、居宅介護支援事業者から要介護者への計画書・提供票の提示はあるものの、説
明がほとんどない場合もあり、介護の素人である要介護者やその家族にとっては、介護サービスが適切であるかの判断はもちろん、例え毎月同じサービスの提供等のおざなりな対応があったとしても、その状況を正確に把握することが出来ない状況である。
② 解決の方向性
将来的に「介護ネットワークシステム」により蓄積した介護情報を基に、市町村が以下のようなサービスを要介護者やその家族に展開することが解決策として考えられる。
考えられるサービスの例を以下に示す。

40

○介護サービス実績の速報通知サービス
サービス提供月の翌月に、要介護者またはその家族に向けて、前月分のサービス提供
実績を電子メールで送付し（希望に応じて郵送も可とする）、内容を確認してもらう。確認の結果、疑義がある場合は、市町村に連絡してもらう。
要介護者及び家族に対して、介護サービスの実績の通知を行うことで、介護事業者に対して不適切なサービスの抑止力となる。但し、請求額や単位数に関しては、審査後の確定情報ではない事に注意する必要がある。

○計画書・提供票閲覧サービス「介護ネットワークシステム」の追加機能として、要介護者及び家族が自宅のＰＣから計
画書・提供票の情報を過去に遡って確認できる機能を設ける。これにより、要介護者及び家族が、介護情報を時系列で確認することが出来る。
ただし、一般の家庭が接続しているインターネットで閲覧することから、閲覧権限等含めて、十分なセキュリティ対策を行う必要がある。

（３） 介護予防事業への展開① 現状の問題点
前述したように、要支援・要介護者の増加に伴い、介護給付費も全国的に増加の一途を辿っており（平成 19 年 7 月は 4,900 億円であり、平成 12 年 6 月の 2,200 億円の 2 倍以上となっている）、このまま要支援、要介護者が増え続けると各自治体の財政を大きく圧迫することは必至である。一方で、介護サービスを提供する人的リソースの不足も深刻である。今回、要介護度が進むことを予防するためのひとつの手段として、予防給付の計画書
等の介護情報の捕捉をあげたが、そもそも、高齢者が要支援、要介護にいたることを予防するしくみ・情報システムが必要である。しかし、現在は、医療・保健・福祉のシステムが一貫性や継続性に欠け、適切に機能していない。
② 解決の方向性
各自治体においてこれらの課題の解決を図る具体策として、自治体において把握可能な住民健診などの情報を元に、ハイリスク者のスクリーニングを行い、健康指導や運動指導を行う要支援・要介護へ進まないためのサービスの提供と、地域包括支援センター等を中心として、関連する部署間の横の連携を強化するしかけがあげられる。そして、これを支えるためには、本基本検討書で検討してきた要介護者の介護サービス情報の見える化のための「介護ネットワークシステム」を、介護に至る前の高齢者の健康情報の見える化に拡張した情報システムが必要である。もちろん、介護ネットワークシステム同様、人とシス
テムのスムーズな連携を考慮し、マンパワー等の限りあるリソースを有効、且つ効率的に利用していく工夫が重要であるのは言うまでもない。
なお、本医療ワーキンググループの EHR（健康領域）プロジェクトにおいて、「生涯健康情報基盤」の検討が行なわれている。これは「個人の健康情報を長期にわたり収集し、コンピュータ処理可能な形式で保存し利活用できるようにした仕組み」として検討されている

41

が、介護予防事業が個人の長期かつ多様な健康情報の利活用を必要とし、地域における各職種間の連携が求められる事業であることから、介護ネットワークシステムの拡張に際し、この仕組みを利活用する効果は高いと考える。
今後は、プロジェクト間の連携も行い、介護ネットワークシステムを介護予防に向けた高齢者の健康情報の見える化にも拡張していくための検討を進めるとともに、各自治体の状況に則した提案を進めていく。

病院ｱﾌﾟﾘｹｰｼｮﾝ
病院

診療情報
診療情報
レセプト情報健康推進アプリケーション(ＥＨＲ−ＰＴ)

住民

健診ｱﾌﾟﾘｹｰｼｮﾝ

・健診情報
・診療情報
・要介護情報・・

自治体
健診情報

健診情報

健診情報

統計情報

・統計情報

要介護情報
介護サービス情報
介護予防情報等

健診情報

負傷情報
健診情報

介護ｻｰﾋﾞｽｱﾌﾟﾘｹｰｼｮﾝ(介護ＰＴ)

災害時医療支援ｱﾌﾟﾘｹｰｼｮﾝ(ＮＷセキュリティＰＴ)

・介護サービス情報
・ＡＤＬ他要介護情報
・介護予防情報

・健診情報
・負傷情報
＋α

図５−１ PT 連携システムの図

42

関連機関

【介護ネットワークサービスプロジェクトメンバ】
プロジェクトメンバ

役割

株式会社日立製作所

リーダー

富士通株式会社

メンバ

株式会社エヌ・ティ・ティ・データ

メンバ

エヌ・ティ・ティ・コミュニケーションズ株式会社

メンバ

財団法人加古川総合保健センター

メンバ

ＮＰＯ法人医療ネットワーク情報センター

メンバ

厚生労働省 介護保険課

オブザーバ

総務省

オブザーバ

ＡＰＰＬＩＣ

事務局

43

別添資料１

先進事例調査１．東京都国保連合会「国保連合会介護給付適正化システム」 ··············· 2
２．島根県 松江市 「介護情報メッセージ交換システム」··············· 7

３．兵庫県 加古川地域「二市二町コミュニティケアネットシステム」 ······· 14
４．北海道 美唄市 「介護予防システム」

1····························· 19

１. 東京都国民健康保険連合会 「国保連合会介護給付適正化システム」〜調査の目的〜
介護給付適正化に向けて、各都道府県国保連合会が運用し、保険者に情報提供を行っている「国保連合会介護給付適正化システム」、東京都国保連合会が独自に導入している「ケアプラン
分析システム」の機能・活用方法を把握し、「介護ネットワークシステム」が保険者に情報提供できる内容との差異を把握する。

１.１ システムの概要
東京都国保連合会では、以下に示す 2 つのシステムを利用し、介護事業所の請求情報等の分析を実施し、保険者及び都道府県に情報提供を行っている。
（１） 「国保連合会介護給付適正化システム」
介護給付費の審査・支払を行っている各都道府県国保連合会が、介護事業所から送付された請求情報や、都道府県の事業所情報等を用いて、保険者及び都道府県に情報提供を行う事を目的に国保中央会が開発したシステムである。
以下に、国保連合会の審査支払システムの概要図を示す（図１−１）。
「国保連合会給付適正化システム」では、審査の結果情報を基に分析したデータを保険者
及び都道府県に提供している。

※ 東京都国保連合会は医療レセプト情報との突合分析も実施 （東京都国保連合会 提供資料）（東京都国保連様 提供資料）【出典：「東京都国保連合会提供資料（2007 年 8 月提供）」】

図１−１ 審査支払システムの概要図2

（２） 「ケアプラン分析システム」「給付適正化システム」と同様のインプットデータを基に、保険者がより活用し易いデータで情報提供を行う事を目的に東京都国保連合会が独自に導入しているシステムである。
「居宅介護サービス計画書」の情報は、分析対象としておらず、「給付管理票」等の請求情報を基に分析を行っている。
平成 18 年度時点で、全国で約 8 連合会が導入している。

１.２ システムのインプット情報「国保連合会介護給付適正化システム」、「ケアプラン分析システム」に用いるインプット情報を以下に示す。
（１） 「国保連合会介護給付適正化システム」のインプット情報
給付管理票、明細書（請求情報）、受給者情報、事業所情報、医療レセプト（老人保健分）
をインプット情報として使用している。全ての国保連合会で統一ではないが、給付管理票、明細書（請求情報）は確定してから 2 ヵ月後のデータ（サービス提供月の 3 ヵ月後）が分析の対象となる。
（２） 「ケアプラン分析システム」のインプット情報
給付管理票、明細書（請求情報）、受給者情報、事業所情報※基本的には「国保連合会介護給付適正化システム」のインプット情報と同様となる。国保連合会が保有している電子データを用いて分析を行う。

１.３ 主なシステム仕様「国保連合会介護給付適正化システム」、「ケアプラン分析システム」のシステム仕様を以下に記載する。
（１） 「国保連合会介護給付適正化システム」① システム機能
上記のインプット情報を利用して、介護給付費の縦覧点検、突合点検、医療情報との突合（注 1）を行っている。提供するデータ形式は Excel データとなる。
また、保険者（都道府県）からの WEB 検索条件に基づき、集計する機能を有する。
介護給付適正化システムの主な分析項目を表１−１に、情報提供の方式を表１−２に示す。
（注 1）：「縦覧点検」、「医療情報との突合」は、一部の国保連合会のみが実施

3

表１−１ 介護給付適正化システムの主な情報提供項目＃

提供情報項目

提供先

1

更新認定被保険者一覧表

保2

サービス計画費作成体制状況一覧表

保/県3

運営基準減算状態の状況把握表

保/県4

訪問介護サービス提供責任者数の状況一覧表

保/県5

定員超過・人員基準欠如状態の継続表

保/県6

定員超過・事業所一覧表

保/県7

介護支援専門員あたり給付管理票作成状況一覧（都道府県向け）

8

介護支援専門員あたり給付管理票作成状況一覧（保険者向け）

9

１種類サービスによるサービス計画一覧表

保/県

10

同一・近似サービス事業所一覧表

保/県

11

給付急増事業所一覧表（都道府県向け）

県

12

給付急増事業所一覧表（保険者向け）

保13

支給限度額一定割合超一覧表

保/県

14

要介護度の偏りがある事業所一覧表

保/県

15

福祉用具貸与一覧表保/県

16

提供サービス１回あたりの単位数に偏りがある事業所一覧表

保/県

17

支援事業所とサービス事業所の関係一覧表

保/県

18

事業所の請求等決定状況一覧表

保/県

19

要介護状態区分の変更履歴

20

給付詳細情報一覧表

保/県21

事業所別サービス状況一覧表

保/県

22

受給者別給付状況一覧表

23

事業所別サービス状況一覧表（年度）24

受給者別給付状況一覧表（年度）

保25

適正化等による申立件数・効果額（都道府県向け）（総括表・明細表）

県

26

適正化等による申立件数・効果額（保険者向け）（総括表・明細表）

保27

認知症対応型共同生活介護入居者一覧表

保28

大規模事業所減算請求状況一覧表

保/県

29

居宅介護支援請求状況一覧表（総括表・明細表）

保/県

30

訪問介護における特定事業所加算請求状況一覧表

保/県

31

他保険者利用の地域密着型サービス一覧表

32

全体総括表

保/県

33

全国平均・連合会内平均値

連合会

34

介護報酬支払額上位事業所リスト

県35

全事業所支払額リスト

県

県
保

保

保
保/県

保

【出典：国保中央会「国保連合会介護給付適正化システム＜提供情報活用マニュアル＞」】4

表１−２ 情報の提供方式
＃

方式

概要

業務の流れ

定期的な

国保連合会が統一的に抽出処理を実施

情報提供

定期的（1/月）に保険者に抽出結果を送付

1①国保連合会による定期的な情報抽出②抽出結果を保険者に送付③保険者が分析・評価に利用

2

保険者が必要に応じて抽出・検索条件を設定①保険者独自の視点で抽出条件を設定

保険者が設定した検索条件に従い、国保連合②国保連合会が情報抽出

会にて一括抽出処理を行い、抽出・検索結果を③抽出結果を保険者に送付

保険者に送付④保険者が分析・評価に利用

ＷＥＢ検索【出典：国保中央会「国保連合会介護給付適正化システム＜提供情報活用マニュアル＞」】② ネットワーク
保険者（及び都道府県）への情報提供に関しては、基本的には INS64 回線を使用している。ただし、横浜市や大阪市などの大規模保険者の場合は、データ量が多くなり、伝送速度の関係から MO での提供を行っている場合もある。基本的には、提供は１/月となる。
③ セキュリティ
INS64 回線を利用することを前提とし、ID、パスワード、電話番号により利用者の特定を行うことで、セキュリティを確保している。一部、NTT が提供している「グループセキュリティ
サービス」を活用して暗号化伝送を行っているケースもある。
（２） 「ケアプラン分析システム」「国保連合会介護給付適正化システム」と比較して、視覚的に見やすいアウトプットを保険者に提供している。
アウトプットは、個人情報を含まず、CD-ROM で保険者に提供している。「国保連合会介
護給付適正化システム」と同様に、基本的には１/月の提供となる。

5

１.４ 利用状況・活用方法
東京都では、62 保険者の内半分程度が「国保連合会介護給付適正化システム」、「ケアプラン
分析システム」のいずれかを利用している。
保険者側の情報の活用方法としては、以下の３点が多い。
＜主な活用方法＞
・サービス実績の集計（サービスの利用状況等）
・介護事業所ごとの傾向把握（サービスの提供状況等）
・介護事業所指導への活用（サービスの偏り、疑義のある請求等）

また、いずれのシステムも活用していない理由としては、以下の２点が多い。
＜活用していない理由＞
・人手不足により、情報が提供されても事業所調査等を実施できない・送付された情報の活用方法がわからない「活用方法がわからない」保険者のフォローとして、東京都国保連合会では、活用方法について定期的に説明会を実施し、利用者が増えるように努めている。

１.５ 利用料「国保連合会介護給付適正化システム」、「ケアプラン分析システム」に関して保険者（都道府県）からは、利用料は徴収していない。
システムでの分析情報の提供も、介護給付の突合審査の委託費に含めている。

１.６ 課題システムの分析情報を用いることで、保険者が介護事業所の傾向を掴むことは出来る。ただし、それが不適切かどうかは、保険者が実態調査を行って判断しなければならない。分析結果のチェ
ックの方法や優先順位等まで国保連で示すことが出来れば、より保険者が活用しやすくなる。
また、事業所間の情報連携は対象外なこと、また、分析のもととなるデータは、サービス提供月から数ヵ月後になり、必ずしもタイムリーでないこと、さらに計画書のデータは含まれないため、適正なケアプランが策定されているかといった定性的な分析に踏み込めないといったことがある。

6

２. 島根県 松江市 「介護情報メッセージ交換システム」〜調査の目的〜
保険者が運営し、介護事業者間の電子データによる情報共有を実現している島根県松江市の「介護情報メッセージ交換システム」のシステム概要、運用方法、事業立ち上げ時の課題を把握する。

２.１ 事業概要
平成 14 年度に経済産業省のモデル事業（JAHIS が実施）で介護事業者間の情報共有（主に居宅介護サービス計画書、サービス提供票）を目的に、「介護情報メッセージ交換システム」（共有サーバを松江市に設置）を構築し、介護事業者間の情報共有に向けた情報基盤を構築した。
また、翌年度の平成 15 年度に厚生労働省の「介護サービス及び費用適正化のモデル事業」に採択され、「介護情報メッセージ交換システム」の不具合や要求点を検討し、再構築を行い、現在も運用している。
松江市のこれまでの介護事業における取り組みを表１−１に示す
表１−１

松江市でのこれまでの取組み

年度
平成 13 年度

主な取組み
○要介護度の経時変化の実態把握○高齢者の機能低下の実態把握○歩行／摂食機能の実態把握と既存サービスの効果評価①健康高齢者と軽度要介護者間の生活機能の差異の検証

平成 14 年度

②アセスメント／効果評価項目の検討③既存サービス（パワーリハ等）の効果評価の実施○事業者間の情報交換システムの開発（経産省

JAHIS モデル事業）○軽度要介護者等へのリハビリプログラムの構築（通所介護を中心に、継続可能なプログラムを開発）
平成 15 年度

○厚労省の「介護サービス及び費用適正化のモデル事業」に採択され事業者間の情報交換システムの再構築○住民に対する生活機能アンケート調査

平成 16 年度

○地域支援モデル事業の実施（課題の抽出）○介護予防効果評価用システムの開発

現在は、「介護情報メッセージ交換システム」の情報基盤を用いて、主治医意見書や各介護事業者が保有している要介護者の情報（在宅生活療養ノート等）の共有も行っている。

7

２.２ システムの概要
松江市に設置した配信サーバと各介護事業者とを INS64 回線を用いて接続し、CSV 形式のデータでの各種介護情報の共有を行っている。各介護事業者は、松江市が開発し提供している「簡易ソフト」を用いて配信サーバへのデータのアップロード/ダウンロードを行っている。各介護事業者が介護業務で使用している介護ソフトのデータフォーマットは介護ソフトベンダー毎に異なるため、松江市独自の仕様として介護ソフトがインポート/エクスポートするデータ項目を統一している。
「介護情報メッセージ交換システム」の概念図を図２−１に示す。

松江市

配信サーバ

事業者固有情報の取得◇ケアプラン情報◇サービス提供時の
利 用者情報INS回線による独自ネットワーク

居宅事 業所

サ ービス提 供事業所

主治医

簡易ソフト

簡易ソフト

簡易ソフト

介護ソフト

介護ソフト

意見書ソフト

利用者情報の共有（事業者間連携）◇計 画書 、サービス提 供票 、主治医意見書・訪問調査情報 （居宅のみ）◇在 宅生 活療養ノートによる経過 記録及びケアチームとしての意見◇専 門家 （主治医）からのアドバ イス【出典：松江市「介護保険課提供資料（2007 年 9 月提供）」】
図２−１ 「介護情報メッセージ交換システム」概念図

２.３ システムのインプット情報「介護情報メッセージ交換システム」では、利用者情報、居宅サービス計画書情報、サービス提供票（予定/実績）、支給情報、主治医意見書情報、療養ノート情報、訪問調査情報を共有している。なお、共有している情報のデータ形式は CSV 形式である。

8

２.４ 主なシステム仕様「介護情報メッセージ交換システム」の主なシステム仕様を以下に示す。
（１） システム機能概要（松江市様提供資料を参考に作成）「介護情報メッセージ交換システム」の①配信サーバ（松江市役所に設置）、②簡易ソフト（各介護事業所に設置）のシステム機能を以下に示す。
① 配信サーバの機能（ア） 計画書・提供票（予定/実績）メッセージ交換機能
配信サーバを介して計画書・提供票（予定/実績）の CSV データを介護事業所間で送受信する機能である。
（イ） 主治医意見書（アドバイス）、療養ノート等の共有機能
主治医や介護事業所が登録した要介護者に関わる情報を共有する機能である。
② 簡易ソフトの機能
介護事業所の端末に実装している「簡易ソフト」の機能を以下に列挙する。
（ア）サービス担当者会議支援機能
・サービス実施状況とコメントの登録・送信/照会・受信機能・計画書・提供票の画面参照機能
・計画書・提供票の内容変更者一覧表示機能
・システム未参加の事業者へのＦＡＸ送信機能
・各種情報の印刷機能（イ）保険者及び事業者間の伝言メモ機能
・居宅介護支援事業者、サービス事業者、医療機関、保険者間での伝言メモ機能
・配信サーバへのアップロード/ダウンロード機能

9（２） ネットワーク
介護事業所の端末と共有サーバは INS64 回線で接続している。保険者側の端末と配信サーバは市役所内のＬＡＮで接続している。
（３） セキュリティ対策
基本的には、INS 回線を用いた閉じたネットワーク内での情報共有を行っている。加えて、介護事業所からのダイヤルアップ時は、回線番号、ユーザーＩＤ、パスワードでアクセス制御し、データ転送時は、データの暗号化を行っている。ユーザーＩＤは、介護事業所番号を基本とした事業所単位としている。

10

２.５ システムの利用状況「介護情報メッセージ交換システム」には、松江市内の多数の介護事業者がシステムに参加している。システムを導入している介護事業者が業務効率化を実感しているため、周囲の多数の事業者が参加していると考えられる。
2007 年時点でのシステム参加事業所数を以下に示す。
＜システム参加事業所数＞ ※分母は松江市全体での事業所数
居宅介護支援事業所：

48 事業所／57 事業所

介護サービス事業所：

100 事業所／100 事業所※但し、福祉用具貸与は含めない【出典：松江市「介護保険課提供資料（2007 年 9 月提供）」をもとに作成】

２.６ コスト負担（１） イニシャルコスト
イニシャルコストに関しては、前述のように、平成 14 年度の経済産業省モデル事業、平成
15 年度の厚生労働省モデル事業の費用を利用してシステム構築・見直しを行った。
そのため、イニシャルコストをランニングコストで回収する必要がなく、ランニングコストを安価に押さえることが出来ている。
（２） ランニングコスト
共有サーバ側のハード・ソフト及び保険者が介護事業所に無償で提供している簡易ソフト
に関しては、保険者が費用を負担している。回線費用は、保険者、介護事業所のそれぞれが負担している。
システムの改修等に関わる費用に関しては、保険者とシステムに参加している介護事業所
で 51：49 の割合で負担している。システムに参加している介護事業所からは１事業所あたり
1,000 円/月を利用料として徴収している。
各介護事業所が業務で使用している介護ソフトに関しては、各介護事業所で費用を負担し
ている。

11

２.７ 課題「介護情報メッセージ交換システム」の事業化までの課題、運用上の課題、今後の課題を示す。
（１） 事業化までの課題① 介護事業者との目的の共有「システム化」が目的ではなく、システムを構築する事で、「どんな情報を集め、何のために使用するのか」、「情報を共有化する事にどんな意味があるのか」、「システム化することで事業者業務が軽減される事」等をシステムに参加する介護事業所に理解してもらう事が課題であった。
松江市では、平成 14 年度のモデル事業以前から保険者と介護事業者が良好な関係を築く事が出来ていたため、介護事業者と共に連携のあり方等を検討することで、目的を共有できている。
② 交換データの統一
前述のように、介護ソフトのデータ項目は、統一されておらず、介護ソフトベンダー毎に異なる。「介護情報メッセージ交換システム」を事業化するにあたり、参加する介護事業者の使用しているデータ項目を統一する必要があった。
平成 14 年度の経済産業省のモデル事業での実績を基本に松江市での基準を作成し、介護ソフトベンダーに準拠してもらう必要があった。現在共有しているデータ項目（サービス計画書、サービス提供票）は、JAHIS が規定した「介護標準メッセージ」（XML）と互換性のあるデータ項目を使用している。
システムに参加するために、松江市のデータ項目に対応してくれる介護ソフトに乗り換える介護事業者も少なくなかったため、松江市内で使用される介護ソフトの種類も次第に集約された。
（２） 運用上の課題
運用上の課題としては、制度改正時の対応時期の問題と対応範囲が大きいという点がある。前述のように介護ソフトベンダー側から見ると松江市のデータ項目は独自仕様となってしまうため、制度改正の対応が遅れる傾向がある。

12

（３） 今後の課題（事業の展開、向上に向けた課題）「介護情報メッセージ交換システム」の今後の課題を以下に列挙する。
① ネットワーク環境の見直し
現在使用している INS64 からインターネット等の高速回線の利用による業務の効率の向上が介護事業者から望まれている。実現に向けては、セキュリティについて十分な検討を行う必要がある。
② 介護ソフトの標準化・規格化
前述の通り、連携データとして JAHIS が規定した「介護標準メッセージ」と互換性のある
データ項目を利用している。しかしながら、介護ソフトの仕様は開発ベンダによって大きく異なるため、同じデータ項目であっても「選択式で入力」と「記述で入力」では、データの粒度が異なる。介護ソフト間のデータの粒度も含めた標準化が必要である。
③ 要介護者本人・家族の参画集約した情報を活用した要介護者本人や家族へのサービスの拡充が望まれる。
④ 保健・医療情報との統合集約した介護情報と 2008 年 4 月から開始される特定健診や高齢者の医療情報との連携が望まれる。
⑤ 地域での情報の分析・評価集約した介護情報の活用に向けて、具体的な課題の設定と評価指標を定める必要がある。

13

３. 兵庫県加古川地域「二市二町コミュニティケアネットシステム」〜調査の目的〜
兵庫県加古川地域における「二市二町コミュニティケアネットシステム」の概要を調査し、運営されている介護情報システムにおける要介護者・ケアマネージャー・介護事業者・医師の情報共有と交換の手法をみる。そしてそれらがどのように介護サービスの質的向上に寄与しているかを把握する。

３.１ システム全体の概要
兵庫県加古川地域（加古川市、稲美町、播磨町）では、住民が「いつでも、どこでも、だれでも」等しくかつ最適な医療を受けられる環境を目指し、「加古川地域保健医療情報システム」を運用している。これは地域住民の検査・健診データや、各医療機関で発生する医療情報、健康福祉事務所・市町および保健センターで把握した個人の様々な健康に関するデータをホストコンピュータで集約し、それらを活用して関係機関が地域住民に対し、適切なサービスを供給し支援できるシステムである。財団法人加古川総合保健センターが運用主体となって、平成 6 年から正式供与が開始されている。
本システムは、保健・医療・福祉の三位一体の連携を根幹思想としており、当然ながら介護分
野での利用も含むものである。介護分野への対応は「福祉システム」の活用に位置付けられていたが、平成 14 年 5 月より、利用者へのよりよい介護サービスの提供を支援するため、「二市二町コミュニティケアネットシステム」が運用されている。

３.２ 「二市二町コミュニティケアネットシステム」の特徴「二市二町コミュニティケアネットシステム」は「介護サービスの質の向上」「介護サービスの公平性の確保」「要介護者による介護サービスの選択」などを目的としており、これによって住民が老後を安心して暮らせる地域社会を目指している。前出の 1 市 2 町に加え、高砂市が当該システムにのみ参加し、2 市 2 町での運営となっている。
当該システムの特徴は以下の 4 点である。
（１） 要介護者とその家族に対するサービスの確保と質の向上
地域内の多数の介護サービス事業者が参画し、活用することにより、提供する各種介護サービスの格差の縮小や、情報の共有化による質の向上が図られる。
（２） ケアマネージャーにおけるケアプラン作成業務の軽減
ホストサーバに地域内の各サービス提供事業者が提供可能なサービス内容を一元管理することにより、ケアマネージャーは電話や FAX 以外にシステム（予約照会機能）を利用
しケアプラン作成時における予約業務を効率的に行なえる。

14

（３） 介護サービス事業者の事務の軽減
従来、介護サービス事業者はケアマネージャーから介護サービスの予約・調整等に対し個々に対応していたものを、システムにより予約・調整などの作業を一括で管理することができ、それら業務に関わる作業の負担を軽減することができる。
（４） グループウェアの利用による円滑なチームケアの実現
要介護者に関する情報をグループウェア機能を用いて共有することにより、ケアマネー
ジャー・介護サービス事業者・サービス提供担当者・医師・行政などそれぞれの立場からチームとして対応にあたることができる。

図１−１ 【加古川地域保健医療情報システム】と【コミュニティケアネットシステム】概要図

15

３.３ システムのインプット情報「二市二町コミュニティケアネットシステム」に用いるインプット情報を以下に示す。
・「二市二町コミュニティケアネットシステム」のインプット情報
基本情報、家族・住居、既往歴・現病歴、かかりつけ医、居宅療養管理指導、介護上の留意点、介護サービス計画書、安心カレンダー情報（予約情報）、サービス提供情報（予定・実績）、介護日誌、ケアカンファレンス情報、介護サービス予約情報、介護サービス
提供情報

３.４ 主なシステム仕様「二市二町コミュニティケアネットシステム」のシステム仕様を以下に記載する。
（１） システム機能① 「要介護者フォーラムシステム」
ケアマネージャーが入力した要介護者の情報、主治医が入力した居宅療養管理指導に関わる内容などを介護スタッフ間で共有する機能である。担当する要介護者のケアカンフ
ァレンスを実施することも可能である。
また、上記のインプット情報から、ケアマネージャーが要介護者の近況を確認することができ、同様に介護事業者は、要介護者情報を事前に参照したり、介護サービスを提供後にその状況を報告する（これが介護日誌情報となる）。

図１−２ 要介護者フォーラムシステムのシステムイメージ図

16② 「予約照会機能」
ケアマネージャーが、要介護者の希望する介護サービス(提供可能な事業者と日時)を迅速に予約する機能である。サービス実施後に介護サービス事業者は予定に対する実績を登録する。ケアマネージャーは、入力された実績を参照し、サービス提供状況を確認する。
③ 「情報ネットワーク機能」
システム利用者間で掲示板を用いて情報共有する機能である。医師、介護スタッフ間などの個人間でメッセージをやりとりする。システムに参加する介護スタッフ全員が個人情報
以外の介護に関わる意見交換を行う。
（２） ネットワーク
各拠点間は、ADSL（OCN）、光ファイバーを利用している。ISDN でも利用可能である。
（３） セキュリティ
正規の利用者であるかの判別をユーザー認証によって特定し、送受信するデータの暗号化を行うプライベートネットワーク(VPN)を構成している。

17

３.５ 利用状況・活用方法
同意者数： 1,321 人 / 約 5,000 人
参画事業者数:：217 事業所/ 356 事業所（平成 19 年 12 月現在)
＜主な活用方法＞
・要介護認定後、ケアマネージャーが要介護者の近況などを参照し、ケアプランを作成する。
・介護事業者が、要介護者情報を参照し、ケアプランに沿った介護サービスを提供する。
・介護事業者は介護ケアを提供後、実施状況を登録する。

３.６ 利用料・利用者（ケアマネージャー、介護事業者）の負担は、回線費用（固定）のみであり、また住民の費用負担はない。
・イニシャルコスト、ランニングコストとも、全て自治体の予算で負担しており、イニシャルコス
トは約 2 億円、ランニングコストは年間に 3,000 万円となっている。

３.７ 課題（１） 自治体情報の提供
コミュニティケアネットシステムで集約・共有する情報において、訪問調査・主治医意見書および要介護者情報など、自治体が管理する情報提供を有効活用し事務の迅速化や効率化を図りたいとの要望が大きい。
（２） 介護実施状況の情報開示システムでは、介護実績情報やケアカンファレンスなどの内容を要介護者や家族も参照
可能な仕組みとなっているが、実運用ベースでの利用は今後の課題である。
（３） サービス提供の範囲
地域外などシステムに参加されていない事業所とは、従来からの手段(電話・FAX)でや
りとりし、「紙」運用が継続されることから、事務処理上の混在がかえって負担となる場合もある。

18

４. 北海道 美唄市 「介護予防システム」〜調査の目的〜
急速に進む高齢化に対応し、自治体の政策課題として要介護率を低下させることを目的として高齢者の介護予防対策に取り組んでいる北海道美唄市における「介護予防支援システム」のシ
ステム概要、運用方法、事業立ち上げ時の課題を把握する。

４.１ 事業概要
高齢化が急速に進む同市において、高齢者の方々が住み慣れた地域で健康でいきいきと生活するためには、介護を必要としないための備えである「介護予防」がますます大切となる。
そのような課題認識の上で、高齢者の方々には人や地域とのつながりを感じつつ楽しみながら
介護予防指導を受けられるとともに、行政にとっては健康づくり・介護予防指導をより多くの方により簡単かつ効率的に伝えることで更なる指導業務の効果向上を目指して、平成 16 年度からブロードバンドを用いた介護予防事業等に取り組んでいる。
また本事業において同市は、介護予防(｢東京都老人総合研究所｣)及びＩＴ技術の先端的な研究成果を取り入れた先進的・先導的な取り組みを行っており、全国水準の介護予防を目指すことにより、「福祉のまちづくり」の質的レベルアップを図ることを目指している。
取り組み意義・

介護予防のノウハウの導入（介護予防プログラム）

・

介護予防に向けた人材育成（保健師等）

・

介護予防の先端情報収集、人脈づくり（「東京都老人総合研究所」等）

・

新たな介護予防対策への貢献（全国初の先進的・先導的な取り組み）

４.２ システムの概要
ブロードバンドを用いた介護予防事業を平成 15 年度には試行的に、16 年度からは本格的に導入した。
市内に在住する 65 歳以上の高齢者に調査票（老研式活動能力指標）を送付し、回答があった
方に老年症候群リスク判定を行い、リスク保持者には健診案内を郵送する。受診者の中から転倒や尿失禁のリスクの高い方をスクリーニングし、その方を対象に、東京都老人総合研究所のノウ
ハウを活用した介護予防プログラムによる介護予防指導を実施する。

19

介護予防プログラムの実施パターン
パターン 1：ブロードバンドを用いた介護予防プログラムの配信（在宅転倒予防、尿失禁予防体操など）
パターン 2：地域の会館を活用した集団での介護予防プログラム（転倒予防体操）の実施
参加者の実施状況は、システム上で保健師や看護師がモニタリングすることができるため、運動プログラム実施中の励ましや、定期的な継続奨励も実施可能である。

○介護予防支援システムの主な機能 （東京都老人総合研究所の研究成果をシステムに導入）
老化健診分析

改善指導要領・住基ﾃﾞｰﾀからの対象高齢者情報取込機能・老化ｱｾｽﾒﾝﾄによる介護ﾊｲﾘｽｸ者抽出機能・介護ﾊｲﾘｽｸ者の老化健診結果からの老化要因特定機能・老化要因別改善指導要領自動生成機能

老化改善指導・映像を中心とする改善指導要領に基づいた
老化改善指導機能・高齢者の改善指導の実施状況を映像ﾓﾆﾀ
ﾘﾝｸﾞし、進捗状況を分析する機能

双方向老化改善指導
老化健診

行動モニタリング
行動ﾓﾆﾀﾘﾝｸﾞ・高齢者の行動をﾓﾆﾀﾘﾝｸﾞする機能
・ﾓﾆﾀﾘﾝｸﾞ結果を閉じこもり情報として老化改善指導APにｱｯﾌﾟﾛｰﾄﾞする機能【出典：美唄市提供資料】
図４−１ 美唄市における【介護予防システム】概要図

４.３ システムのインプット情報「介護予防支援システム」におけるインプット情報は以下の通りである。
・

住基情報（手入力）、基本健康診査情結果、体力測定結果、問診結果、国保の被保険者
情報、介護保険の被保険者情報、障害者情報、社会保険加入者情報（出張健診での健診結果は、保健師による入力）

・

事業開始した平成 16 年度以降の全参加者データが蓄積共有している情報のデータ形式はテキスト・データであり、汎用性の高い CSV 形式である。

20

４.４ 主なシステム仕様「介護予防システム」のシステム仕様を以下に記載する。
（１） システムの機能｢東京都老人総合研究所｣の研究成果に基づいた「介護予防支援システム」の機能で可能となるのは以下である。
・ 介護予防対象者の的確な把握を目指し、スクリーニングの実施⇒「必要な人に必要なサービスを提供」
・ 効果的な介護予防プログラムによる指導訓練の実施
・ 高齢者のニーズに対応した多様な介護予防事業メニューの提供

介護予防支援システム
介護予防支援システム

転倒骨折予防指導
転倒骨折予防指導

一般健診
一般健診

ス
ス

対
対

ク
ク

象
象

リリ

者
者

｜
｜
指導前健診
指導前健診

尿失禁予防指導
尿失禁予防指導

別
別

ニ
ニ

に
に

ン
ン

実
実

グ
グ

施
施

指導後健診
指導後健診
3ヶ月間
3ヶ月間

その後の
その後の

継続
継続

フォローアップ
フォローアップ

低栄養改善食事指導
低栄養改善食事指導

閉じこもり予防指導
閉じこもり予防指導【出典：美唄市様提供資料】
図４−２ 介護予防システムのシステムイメージ図21

（２） システムの構成「介護予防支援システム」の構成は以下の通りである。
・ 対象者に対しては、パソコン及び周辺機器を貸し出し、インターネットを経由して、自宅での閲覧、及び自己の運動情報のアップロードを行う
・ 集団運動の際は、公民館などへパソコンを設置し、スタンドアロン型での運動指導を行う
・ 実施状況のデータや実施画像はデータセンターで管理している・ 「東京都老人総合研究所」が作成したコンテンツはサーバで管理している【出典：美唄市提供資料】
図４−３ 美唄市介護予防システム全体構成図（３） システムの特徴「介護予防支援システム」の特徴は、ブロードバンド配信されてくる介護予防支援プログ
ラムを、システム画面上で見られることである。プロのインストラクタのわかりやすい解説指
導がブロードバンドならではの高画質映像で配信され、また同期配信により、集まって一緒に運動をしている感覚を演出する。
そして多地点テレビ会議により、お茶の間にいながら画面に映る仲間の顔を見ながら楽しく運動ができることで、運動の継続を促進している（図４−４の画面下段）。

22

テレビ
【出典：美唄市様提供資料から作成】
図４−４ 介護予防支援プログラム配信イメージ（４） ネットワーク
・システムと個人宅をつなぐ回線は ADSL を利用している。
・動画のダウンロードには問題ないが、アップロードには速度が足りない問題がある。
（５） セキュリティ
・データ閲覧権限については、美唄市の管理規定に従い ID・パスワード管理されている。
・NTT コミュニケーションズのデータセンターとの通信においては SSL と IPSec により、セキ
ュリティを担保している。

23

４.５ システムの利用状況・活用方法
平成 16 年度の実績としては、全対象者 3,851 人中、アンケートによる第 1 次スクリーニング、その回答結果から介護予防検診「ぴぱ・元気検診」（基本健康審査・体力測定・問診）を実施、受診者 192 名から第 2 次スクリーニングを行なった。その結果は下表のとおりである。「要介護予防」
対象者は 67 人、その中から「介護予防プログラム」が提供されたのは、パソコン貸与による運動
指導対象者が 10 人、集団教室での運動指導対象者が 13 人であった。この 23 人に加え、他のカ
テゴリーからも抽出された別の保健事業で対応する対象者が 71 人おり、いわゆるハイリスク者として介入したのは 94 人であった。
表４−１

平成 16 年度

美唄市介護予防支援システムの結果

カテゴリー

人数（人）

普通

20

保健事業対応

16

要注意

40

治療優先

49

要介護予防

67

＜主な活用方法＞
・介護予防システム 健診 AP にて、基本健康診査の結果を収集する。
・介護予防システム 指導 AP にて、保健師や看護師が指導内容の確認及び指導を実施する。
・被指導者は、自宅（集団指導の対象者は公民館など）のパソコンを通じて、自分に必要な運動指導・食事指導などを受ける。
・被指導者は、運動プログラムを参照しながら、一緒に運動する。
・被指導者は、自分の運動している姿を録画・アップロードし、指導者（保健師・看護師）へ
フィードバックする。

24

４.６ コスト負担「介護予防システム」については、指導対象者（住民）からは、利用料は徴収していない。但し、回線利用料（プロバイダー利用料（OCN））のみは住民負担である。
システム構築費（イニシャルコスト）と運用費（ランニングコスト）は、以下に示す通りである。
＜イニシャルコスト＞＜ランニングコスト＞

４.７ 課題（１） 民間サービス提供事業者との連携
自主的に週１程度でプログラムを実施する集団も出てきているため、民間企業と連携し、自主グループを支援していければと考えている。
（２） 国保（予防医療）との連携「介護予防」と名前はついているが、数値結果をみるとわかるように予防医療に大きく関わる。特定健診が開始されることもあり、国保との連携も検討していく必要がある。
（３） データ保存について
現在の所、事業を開始した平成 16 年度分から全ての参加者のデータ（映像含む）を保持している。死亡や引越し等の情報は更新・削除する必要がある。
運動の映像データについては、全てを保存する必要はないと考えられるので今後データ保存について関係者と検討していく必要がある。

25

別添資料２

業務の流れ（業務フロー）・情報の流れ（ＤＦＤ）＜ＡＳＩＳ・ＴＯＢＥ＞

1

【目次】
１．業務の流れ（業務フロー）·············································
１．１．＜ASIS＞現状業務フロー········································· 3

１．１．１．＜ASIS＞介護サービス計画書の作成・提出······················· 3
１．１．２．＜ASIS＞サービス提供票の作成・提出··························· 4
１．１．３．＜ASIS＞予防サービス計画書の作成・提出（委託） ··············· 5
１．１．４．＜ASIS＞予防サービス提供票の作成・提出（委託） ··············· 6
１．２．＜TOBE＞将来業務フロー········································· 7

１．２．１．＜TOBE＞介護サービス計画書の作成・提出······················· 7
１．２．２．＜TOBE＞サービス提供票の作成・提出··························· 8※地域包括支援センターの委託の将来業務については、自治体によって運用が様々であることが想定されるため省略する。
２．情報の流れ（ＤＦＤ）·················································
２．１．＜ASIS＞現状ＤＦＤ··············································· 9２．１．１．＜ASIS＞介護サービス計画書の作成・提出····················· 9２．１．２．＜ASIS＞サービス提供票（予定）の作成・送付 ··················· 11
２．１．３．＜ASIS＞サービスの実施・サービス提供票（実績）の作成・送付 ··· 14
２．２．＜TOBE＞将来ＤＦＤ··············································· 15
２．２．１．＜TOBE＞介護サービス計画書の作成・提出····················· 15

２．２．２．＜TOBE＞サービス提供票（予定/実績）の作成・送付 ·············· 17※居宅介護支援業務の視点で示す。
２．２．３．＜TOBE＞サービスの実施・サービス提供票（実績）の作成・送付 ··· 19※介護サービス業務の視点で示す。

2

１．１．＜ASIS＞現状業務フロー
１．１．１．＜ASIS＞介護サービス計画書の作成・提出
業務フロー
区分

業務名

ＡｓＩｓ

階層

１．１．１．介護サービス計画書の作成・提出
０※地域包括支援センターが業務委託しない場合◎：手間がかかる部分

居宅介護支援事業者（地域包括支援センター）

介護サービス事業者

計画書の作成計画書の作成（介護ソフトを使用）（介護ソフトを使用）

印刷
印刷

計画書

計画書
提供票
提供票

提出先毎に仕分け◎ 提出先毎に仕分け
（手作業）
（手作業）

計画書提出
計画書提出
（手渡し・FAX）（手渡し・FAX）

計画書
提供票
提供票

計画書
提供票
提供票

受領
受領

紙情報のまま保管
紙情報のまま保管
計画書
提供票
提供票

計画書
提供票
提供票

計画書
提供票
提供票

凡例
処理

紙帳票

電子データ 業務・情報の流れ

3

電子データの流れ システム

コメント

１．１．２．＜ASIS＞サービス提供票の作成・提出
業務フロー
区分

業務名

ＡｓＩｓ

階層

１．１．２．サービス提供票の作成・提出
０※地域包括支援センターが業務委託しない場合◎：手間がかかる部分

居宅介護支援事業者（地域法価値支援センター）

介護サービス事業者

提供票（予定）作成
提供票（予定）作成（介護ソフトを使用）（介護ソフトを使用）

印刷
印刷

提供票
（予定）
提供票
（予定）
提供票
提供票

提出先毎に仕分け◎ 提出先毎に仕分け
（手作業）
（手作業）

提供票（予定）提出
提供票（予定）提出（手渡し・FAX）（手渡し・FAX）

提供票
（予定）
提供票
提供票

受領
受領

サービスの提供
サービスの提供

提供票（実績）作成
提供票（実績）作成（介護ソフトを使用）（介護ソフトを使用）
提供票
（実績）
提供票
提供票

印刷
印刷

提出先毎に仕分け◎ 提出先毎に仕分け
（手作業）
（手作業）

受領
受領

提供票
（実績）
提供票
提供票

提供票（実績）提出
提供票（実績）提出（手渡し・FAX）（手渡し・FAX）◎ 介護ソフトに転記
介護ソフトに転記

凡例
処理

紙帳票

電子データ 業務・情報の流れ

4

電子データの流れ

システム

コメント

１．１．３．＜ASIS＞予防サービス計画書の作成・提出（委託）
業務フロー
区分

ＡｓＩｓ

業務名
階層

１．１．３．介護予防サービス計画書の作成・提出（委託）０※作成から印刷・提出を委託することを想定◎：手間がかかる部分

地域包括支援センター（業務委託先）居宅介護支援事業者

業務委託
業務委託

計画書の作成計画書の作成（介護ソフトを使用）（介護ソフトを使用）

介護サービス事業者
予防
計画書

予防
計画書
提供票
提供票

印刷
印刷

提出先毎に仕分け◎ 提出先毎に仕分け
（手作業）
（手作業）

予防
計画書
提供票
提供票
確認
確認

計画書提出
計画書提出
（手渡し・FAX）（手渡し・FAX）

受領
受領

紙情報のまま保管
紙情報のまま保管※地域包括支援センターが民間介護※地域包括支援センターが民間介護事業所に業務委託する場合、委託時事業所に業務委託する場合、委託時の運用は自治体により異なる。
の運用は自治体により異なる。

予防
計画書
提供票
提供票

予防
計画書
提供票
提供票

凡例
処理

紙帳票

電子データ 業務・情報の流れ

5

電子データの流れ

システム

コメント

１．１．４．＜ASIS＞予防サービス提供票の作成・提出（委託）
業務フロー
区分

ＡｓＩｓ

業務名
階層

１．１．４．予防サービス提供票の作成・提出（委託）０※作成から印刷・提出・給付管理を委託することを想定◎：手間がかかる部分

地域包括支援センター（業務委託先）居宅介護支援事業者

業務委託
業務委託

提供票（予定）作成
提供票（予定）作成（介護ソフトを使用）（介護ソフトを使用）

介護サービス事業者

提供票
（予定）
提供票
提供票

印刷
印刷

提出先毎に仕分け◎ 提出先毎に仕分け
（手作業）
（手作業）

提供票（予定）提出
提供票（予定）提出（手渡し・FAX）（手渡し・FAX）

受領
受領

サービスの提供
サービスの提供※地域包括支援センターが民間介護※地域包括支援センターが民間介護事業所に業務委託する場合、委託時事業所に業務委託する場合、委託時の運用は自治体により異なる。
の運用は自治体により異なる。

提供票（実績）作成
提供票（実績）作成（介護ソフトを使用）（介護ソフトを使用）
提供票
提供票
印刷
印刷 （実績）提供票
提出先毎に仕分け◎ 提出先毎に仕分け
（手作業）
（手作業）

受領
受領

確認
確認

介護ソフトに転記
介護ソフトに転記

提供票（実績）提出
提供票（実績）提出（手渡し・FAX）（手渡し・FAX）
提供票
（実績）
提供票
提供票

凡例
処理

紙帳票

電子データ 業務・情報の流れ

6

電子データの流れ

システム

コメント

１．２．＜TOBE＞将来業務フロー
１．２．１．＜TOBE＞介護サービス計画書の作成・提出
業務フロー
区分

ＴｏＢｅ

１．２．１．介護サービス計画書の作成・提出

業務名
階層

０

居宅介護支援事業者（地域包括支援センター）

介護サービス事業者

システム

計画書の作成計画書の作成（介護ソフトを使用）（介護ソフトを使用）
計画書
計画書のデータを
計画書のデータをエクスポート
エクスポート

計画書
システムから取込システムから取込

介護ソフトにインポート
介護ソフトにインポート※地域包括支援センター※地域包括支援センター
が民間介護事業所に委託
が民間介護事業所に委託する場合は、運用方法にする場合は、運用方法によって設定が必要
よって設定が必要

計画書

介護ネットワークシステム

計画書

システムに送付システムに送付

凡例
処理

紙帳票

電子データ 業務・情報の流れ

7

電子データの流れ システム

コメント

１．２．２．＜TOBE＞サービス提供票の作成・提出
業務フロー
区分

ＴｏＢｅ

業務名
階層

１．２．２．サービス提供票の作成・提出
０

居宅介護支援事業者（地域包括支援センター）

介護サービス事業者

システム

提供票（予定）の作成
提供票（予定）の作成（介護ソフトを使用）（介護ソフトを使用）

提供票（予定）の提供票（予定）のデータをエクスポート
データをエクスポート

提供票（予定）提供票（予定）システムに送付システムに送付システムから取込システムから取込

介護ソフトにインポート
介護ソフトにインポート※地域包括支援センター※地域包括支援センター
が民間介護事業所に委託
が民間介護事業所に委託する場合は、運用方法にする場合は、運用方法によって設定が必要
よって設定が必要

サービスの実施
サービスの実施

提供票（実績）作成
提供票（実績）作成（介護ソフトを使用）（介護ソフトを使用）

提供票（実績）の提供票（実績）のデータをエクスポート
データをエクスポート

介護ネットワークシステム

提供票（予定）提供票（実績）システムに送付システムに送付
提供票（実績）システムから取込システムから取込

介護ソフトにインポート
介護ソフトにインポート
凡例
処理

紙帳票

電子データ 業務・情報の流れ

8

電子データの流れ

システム

コメント

２．１．＜ASIS＞現状ＤＦＤ
２．１．１．＜ASIS＞介護サービス計画書の作成・提出
機能情報関連図（ＤＦＤ）
区分

業務名

ＡｓＩｓ

階層

２．１．１．介護サービス計画書の作成・提出

０

訪問調査情報介護サービス承諾情報
介護サービス計画書承諾情報

要介護者
訪問調査通知情報
介護サービス情報
介護サービス計画書情報
サービス担当者会議開催通知情報

サービス担当者会議開催通知情報
介護サービス内容情報

介護サービス事業者

２ 計画書作成

認定情報
介護サービス計画作成依頼情報

介護サービス計画書情報
認定情報
介護サービス計画作成依頼情報

介護サービス計画書情報

介護計画書台帳

１ 受付

介護サービス計画書情報

３ 送付

凡例

機能

：主に電算処理している機能：部分的に電算処理している機能

機能情報関連図（ＤＦＤ）
区分

業務名

ＡｓＩｓ

階層

：電算処理を行っていない機能

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

２．１．１．介護サービス計画書の作成・提出

１

１．受付

要介護者

認定情報
介護サービス計画作成依頼情報

１−１
受付

認定情報
介護サービス計画作成依頼情報

１−２
認定資格の確認

認定情報
介護サービス計画作成依頼情報

２ 計画作成凡例

機能：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

9

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

機能情報関連図（ＤＦＤ）
区分

業務名

ＡｓＩｓ

階層

２．１．１．介護サービス計画書の作成・提出

１

２．計画作成介護サービス内容承諾情報

要介護者
サービス担当者会議開催通知
介護サービス内容情報
介護サービス計画書情報

訪問調査情報訪問調査通知情報

１ 受付

介護サービス事業者

サービス担当者会議開催通知
介護サービス内容情報

２−２
計画の作成

認定情報
介護サービス計画作成依頼情報

訪問調査情報

訪問調査票

訪問調査情報介護サービス計画書情報
介護サービス計画書情報

２−１
訪問調査
介護計画書台帳
２−３
サービス内容の確定

介護サービス内容承諾情報

３ 送付
凡例

機能

：部分的に電算処理している機能：主に電算処理している機能

機能情報関連図（ＤＦＤ）
区分

業務名

ＡｓＩｓ

階層

１

：電算処理を行っていない機能

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

２．１．１．介護サービス計画書の作成・提出
３．送付

２ 計画作成介護サービス内容承諾情報

３−１
印刷

介護サービス計画書情報

介護サービス計画書情報

介護計画書台帳

３−２
仕分け

介護サービス計画書情報

介護サービス計画書情報

３−３
送付

介護サービス事業者

凡例

機能：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

10

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留２．１．２．＜ASIS＞サービス提供票（予定）の作成・送付
機能情報関連図（ＤＦＤ）
区分

２．１．２．サービス提供票（予定）の作成・提出

業務名

ＡｓＩｓ

階層

０

介護サービス事業者

介護サービス事業者

要介護者
スケジュール回答情報

サービス提供票（予定）情報

スケジュール伺い情報

要介護者
２ 提供票作成

スケジュール情報

サービス利用票（予定）情報
サービス提供票（予定）情報
サービススケジュール情報サービス提供票（予定）情報

１ 調整

３ 印刷・送付
提供票台帳

毎月発生する業務のため、時期がトリガーとなる。
サービス提供票（予定）情報

送付先事業所情報
サービス提供票（実績）情報

４ 給付管理

給付管理情報

国保連合会
凡例

機能

：主に電算処理している機能

機能情報関連図（ＤＦＤ）
区分

ＡｓＩｓ

：部分的に電算処理している機能

業務名
階層：電算処理を行っていない機能

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

２．１．２．サービス提供票（予定）の作成・提出

１

１．調整

要介護者

スケジュール情報

介護サービス事業者
スケジュール伺い情報

１−１
サービススケジュールの検討

スケジュール回答情報

毎月発生する業務のため、時期がトリガーとなる。

サービススケジュール（案）情報

１−２
業者のスケジュール調整

サービススケジュール情報

２ 提供票作成
凡例

機能：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

11

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

機能情報関連図（ＤＦＤ）
区分

業務名

ＡｓＩｓ

階層

１

２．１．２．サービス提供票（予定）の作成・提出
２．提供票作成

１ 調整

サービススケジュール情報

２−１
スケジュールの最終決定
サービススケジュール情報２−２
提供票の作成サービス提供票（予定）情報

提供票台帳

サービス提供票（予定）情報

３ 印刷・送付

凡例

機能：主に電算処理している機能：部分的に電算処理している機能

機能情報関連図（ＤＦＤ）
区分

業務名

ＡｓＩｓ

階層

１

情報名： ゴシック太字下線：電子情報：電算処理を行っていない機能

明朝体細字：電子以外の情報

情報の滞留

２．１．２．サービス提供票（予定）の作成・提出
３．印刷・送付

２ 提供票作成

サービス提供票（予定）情報

３−１
印刷

サービス提供票（予定）情報

３−２
仕分け

サービス提供票（予定）情報

３−３
送付

サービス利用表（予定）情報

サービス利用表（予定）情報

要介護者

４ 給付管理凡例

機能：主に電算処理している機能：部分的に電算処理している機能

サービス提供票（予定）情報：電算処理を行っていない機能

12

情報名： ゴシック太字下線：電子情報

介護サービス事業者

明朝体細字：電子以外の情報

情報の滞留

機能情報関連図（ＤＦＤ）
区分

ＡｓＩｓ

業務名
階層

１

２．１．２．サービス提供票（予定）の作成・提出
４．給付管理介護サービス事業者
３ 印刷・送付サービス提供票（実績）情報

サービス提供票（予定）情報

４−２
給付管理票作成
サービス提供票（実績）情報

４−１
受理

サービス提供票（予定）情報

サービス提供票（実績）情報を介護ソフトに転記

給付管理情報

提供票台帳
４−３
提出

給付管理情報

国保連合会
凡例

機能

：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

13

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留２．１．３．＜ASIS＞サービスの実施・サービス提供票（実績）の作成・送付※レベル０のみ

機能情報関連図（ＤＦＤ）
区分

業務名

ＡｓＩｓ

階層

２．１．３．サービスの実施・サービス提供票（実績）提出※サービス実施等を分解できないため、レベル０のみ

0

要介護者（要支援者）
介護支援事業者（地域包括支援センター）
介護サービス
サービス提供票（予定）情報

２ サービス実施

サービス提供票（予定）情報

１ 受理
介護サービス実施情報

提供票台帳

サービス提供票（予定）情報

サービス提供票（予定）情報

サービス提供票（実績）情報

３ 実績管理サービス提供票（実績）情報

４ 提出

凡例

機能

：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

14

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

２．２．将来ＤＦＤ
２．２．１．＜TOBE＞介護サービス計画書の作成・提出
機能情報関連図（ＤＦＤ）
区分

業務名

ＴｏＢｅ

階層

２．２．１．介護サービス計画書の作成・提出

０

訪問調査情報介護サービス承諾情報
介護サービス計画書承諾情報

要介護者

市町村
介護サービス事業者
介護サービス計画書情報

訪問調査通知情報
介護サービス情報
介護サービス計画書情報
サービス担当者会議開催通知情報

サービス担当者会議開催通知情報
介護サービス内容情報

２ 計画書作成

認定情報
介護サービス計画作成依頼情報
認定情報
介護サービス計画作成依頼情報

介護サービス計画書情報

介護計画書台帳

１ 受付

介護サービス計画書情報

３ 送付

介護サービス計画書情報

介護ネットワークシステム
凡例

機能：主に電算処理している機能：部分的に電算処理している機能

機能情報関連図（ＤＦＤ）
区分

業務名

ＴｏＢｅ

階層

：電算処理を行っていない機能

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

２．２．１．介護サービス計画書の作成・提出

１

１．受付

要介護者

認定情報
介護サービス計画作成依頼情報

１−１
受付

認定情報
介護サービス計画作成依頼情報

１−２
認定資格の確認

認定情報
介護サービス計画作成依頼情報

２ 計画作成凡例

機能：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

15

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

機能情報関連図（ＤＦＤ）
区分

業務名

ＴｏＢｅ

階層

２．２．１．介護サービス計画書の作成・提出

１

２．計画作成介護サービス内容承諾情報

要介護者

介護サービス事業者

サービス担当者会議開催通知
介護サービス内容情報

訪問調査情報訪問調査通知情報

１ 受付

サービス担当者会議開催通知
介護サービス内容情報

２−２
計画の作成
訪問調査情報認定情報
介護サービス計画作成依頼情報

訪問調査票

介護サービス計画書情報

介護サービス計画書情報

訪問調査情報２−１
訪問調査

介護計画書台帳
２−３
サービス内容の決定

介護サービス計画書情報

介護サービス内容承諾情報

要介護者
３ 送付
凡例

機能

：主に電算処理している機能：部分的に電算処理している機能

機能情報関連図（ＤＦＤ）
区分

業務名

ＴｏＢｅ

階層

１

：電算処理を行っていない機能

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

２．２．１．介護サービス計画書の作成・提出
３．送付

２ 計画作成介護サービス内容承諾情報

３−１
登録

介護サービス計画書情報

介護計画書台帳

介護サービス計画書情報

介護ネットワークシステム
凡例

機能：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

16

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

２．２．２．＜TOBE＞サービス提供票（予定/実績）の作成・送付
機能情報関連図（ＤＦＤ）
区分

２．２．２．サービス提供票（予定/実績）の作成・提出

業務名

ＴｏＢｅ

階層

０

※居宅支援業務を中心に示す。
介護ネットワークシステム

介護サービス事業者
サービス提供票（予定）情報

要介護者
スケジュール回答情報

要介護者

スケジュール伺い情報

サービス提供票（予定）情報
スケジュール情報

２ 提供票作成

サービススケジュール情報サービス提供票（予定）情報

１ 調整
提供票台帳
毎月発生する業務のため、時期がトリガーとなる。
サービス提供票（予定）情報
サービス提供票（実績）情報

３ 給付管理

給付管理情報

国保連合会
凡例

機能

：主に電算処理している機能

機能情報関連図（ＤＦＤ）
区分

ＴｏＢｅ

：部分的に電算処理している機能

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

２．２．２．サービス提供票（予定/実績）の作成・提出

業務名
階層：電算処理を行っていない機能

１

１．調整

要介護者

スケジュール情報

介護サービス事業者
スケジュール伺い情報

１−１
サービススケジュールの検討

スケジュール回答情報

毎月発生する業務のため、時期がトリガーとなる。

サービススケジュール（案）情報

１−２
業者のスケジュール調整

サービススケジュール情報

２ 提供票作成
凡例

機能：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

17

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

機能情報関連図（ＤＦＤ）
区分

ＴｏＢｅ

業務名
階層

１

２．２．２．サービス提供票（予定/実績）の作成・提出
２．提供票作成

１ 調整
２−１
スケジュールの最終決定

サービススケジュール情報サービススケジュール情報２−２
提供票の作成サービス提供票（予定）情報

提供票台帳

サービス提供票（予定）情報

要介護者への送付は紙情報のままとなる

２−３
送付サービス提供票（予定）情報

サービス提供票（予定）情報

要介護者

サービス提供票（予定）情報

３ 給付管理凡例

機能介護ネットワークシステム：主に電算処理している機能：部分的に電算処理している機能

機能情報関連図（ＤＦＤ）
区分

ＴｏＢｅ

業務名
階層

１

：電算処理を行っていない機能

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

明朝体細字：電子以外の情報

情報の滞留

２．２．２．サービス提供票（予定/実績）の作成・提出
３．給付管理（※居宅介護支援業務の視点で示す）

介護ネットワークシステム
２ 提供票作成
サービス提供票（実績）情報

サービス提供票（予定）情報

３−２
給付管理票作成
サービス提供票（実績）情報

３−１
取込
サービス提供票（予定）情報

介護ソフトへの転記作業がなくなる

給付管理情報

提供票台帳
３−３
提出

給付管理情報

国保連合会
凡例

機能

：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

18

情報名： ゴシック太字下線：電子情報

２．２．３．＜TOBE＞サービスの実施・サービス提供票（実績）の作成・送付
機能情報関連図（ＤＦＤ）
区分

業務名

ToBe

階層

0

２．２．３．サービスの実施・提供票（実績）提出※介護サービス業務の視点で示す

要介護者（要支援者）
介護ネットワークシステム
介護サービス
サービス提供票（予定）情報

２ サービス実施

サービス提供票（予定）情報

１ 受理
介護サービス実施情報

提供票台帳

サービス提供票（予定）情報

サービス提供票（予定）情報

３ 実績管理サービス提供票（実績）情報

４ 提出
サービス提供票（実績）情報

介護ネットワークシステム

凡例

機能：主に電算処理している機能：部分的に電算処理している機能：電算処理を行っていない機能

情報名： ゴシック太字下線：電子情報

明朝体細字：電子以外の情報

情報の滞留

以上

19

別添資料３

介護ソフトベンダへのアンケート結果＜アンケート実施概要＞
項目

アンケート実施日程

実施内容

平成 19 年 12 月 14 日から平成 20 年 1 月 24 日の回答内容を集計
独立行政法人福祉医療機構サイト「WAMNET」に掲載されている介護保険業務管理ソフトベンダ 57 社を対象に実施

アンケート先の選定＜参考＞「WAMNET」 介護業務ソフト特集
URL： http://www.wam.jp/soft/index.html

送付・回収方法
回答数

送付・回収共に電子メールを利用
20 社/57 社（回収率 35.1％）

1

1-1.居宅サービス計画書第1表〜第3表、提供票・別表のCSVデータのインポート/エクスポート機能を具備している
かお答えください。
エクスポート機能のみ具備している
インポート機能のみ具備している
当該機能を具備していない
その他
無回答
総計
有効回答数

1
1
12
6
0
20
20

インポート/エクスポート機能の具備

5% 5%
30%
エクスポート機能のみ具備している
インポート機能のみ具備している
当該機能を具備して
いない
その他

60%

1-2.上記設問について2,3,4,5とお答えいただいた方に質問です。当該機能を機能追加するためにの概算費用をお答えください。
1,000万円以上400万円以上〜700万円未満
100万円以上〜400万円未満
100万円未満
無回答
総計
有効回答数

1
3
13
2
1
20
19

概算費用
11%

5%
16%
1,000万円以上400万円以上〜700
万円未満
100万円以上〜400
万円未満
100万円未満

68%

2-1.介護予防サービス・支援計画書、提供票・別表は都道府県・市町村によって独自の様式を設定している場合がありますが、御社システムではどのようにカスタマイズ対応しているかお答えください。

厚生労働省様式・東京都様式のみ対応
自治体ごとにソースコード上でのカスタマイズ
Excelなどの中間ファイル上でのカ
スタマイズ
カスタマイズしていない
その他
無回答
総計
有効回答数

カスタマイズ対応

6
4

30%

35%

1
2
7
0
20
20

厚生労働省様式・東京都
様式のみ対応
自治体ごとにソースコード
上でのカスタマイズ
Excelなどの中間ファイル
上でのカスタマイズ
カスタマイズしていない
その他

10%

2

5%

20%

2-2.介護予防サービス・支援計画書 厚生労働省様式のCSVデータのインポート/エクスポート機能を具備している
かお答えください。
インポート/エクスポート両方具備
している
エクスポート機能のみ具備していインポート機能のみ具備している
当該機能を具備していない
その他
無回答
総計
有効回答数

2

インポート/エクスポート機能の具備

1
1
13
3
0
20
20

10%

15%

5%
5%

インポート/エクスポート
両方具備している
エクスポート機能のみ具備している
インポート機能のみ具備している
当該機能を具備してい
ない
その他

65%

2-3.上記設問について2,3,4,5とお答えいただいた方に質問です。当該機能を機能追加するためにの概算費用をお答えください。
400万円以上〜700万円未満
100万円以上〜400万円未満
100万円未満
無回答
総計
有効回答数

3
10
3
4
20
16

概算費用
19%

19%
400万円以上〜700
万円未満
100万円以上〜400
万円未満
100万円未満62%3-1.御社システム内において、提供票データを他事業所間でデータ連携する場合、どのように実現されているかお
答えください。
オンライン上でデータ交換可能
CSV等の中間ファイルを介して可能
FAX送受信機能によるやりとり
当該機能を具備していない
その他
総計
有効回答数
※重複回答あり

4
4
3
7
3
21
21

データ連携の実現

14%

19%

オンライン上でデー
タ交換可能
CSV等の中間ファイ
ルを介して可能19%34%

FAX送受信機能によるやりとり
当該機能を具備し
ていない
その他

14%

3

4-1.JAHISの介護標準メッセージをご存知かお答えください。
名前は知っている
知らない
無回答
総計
有効回答数

10
10
0
20
20

JAHISの認知度

50%

50%

名前は知っている
知らない

4-2.JAHISの介護標準メッセージに準拠した計画書、提供票等のXMLデータのインポート/エクスポート機能について対応する場合、概算費用をお答えください。
1,000万円以上700万円以上〜1,000万円未満
400万円以上〜700万円未満
100万円以上〜400万円未満
無回答
総計
有効回答数

4
2
6
7
1
20
19

概算費用
21%
1,000万円以上

36%700万円以上〜
1,000万円未満

11%

400万円以上〜700
万円未満
100万円以上〜400
万円未満

32%

4

別添資料４―１

介護標準メッセージ仕様【データ定義ファイル内容】（ＸＭＬ Ｓｃｈｅｍａ）

平成 19 年 3 月 改訂
保健医療福祉情報システム工業会

1

「介護標準メッセージ」改訂内容
平成 19 年 3 月
平成 14 年度に策定し、平成 15 年度に改訂した「介護標準メッセージ」について、平成
18 年度の介護保険制度改正を受け、下記の通り改訂する。
＜変更項目＞
改訂理由

メッセージ改訂内容「コード体系」、「データ形式」の変更を実施。
平成 18 年度から介護予防サービスが新設さ ＜変更点＞
れ、要介護度区分が従来の「要支援・要介護 ・「コード体系」の番号７の「11:要支援」を「11：
要支援１」に変更。
「12：要支援 2」を追加。
1・2・3・4・5」から「要支援 1・2、要介護 1・2・3・4・5」に変更。
・「データ形式」の ce07 に「12：enumeration」を追加。
「コード体系」の変更を実施。
平成 18 年度の介護予防サービス、地域密着型＜変更点＞
サービス、地域密着型予防サービスの新設に
・「コード体系」の番号 8 の記載内容を新たなサー
より、サービス種類が変更。
ビス種類に合わせて変更。
「予防サービス計画書情報」の定義を作成。定義作成に伴い、「コード体系」の変更を実施。
＜変更点＞
予防サービス計画書における対応
・「コード体系」に番号 13「領域における課題の有無」を追加。(1:あり、2:なし)「予防サービス提供票情報」の定義を作成。
内容は、「サービス提供票情報」に準拠している。
相違点は、地域包括支援センターの記入欄を定義した点。(PrevHomeHelperOffice のクラス)

予防サービス提供票における対応

また、上記の変更を反映させた XML Schema を新たに作成した。(本資料参照)
なお、新たにメッセージ定義を作成した「予防サービス計画書情報」、「予防サービス提供
票情報」は、標準的な様式が規定されていないため、使用している様式は地域によって異なる場合がある。そのため、制度の動向を押さえつつ、今後も改訂していく必要がある。

以上

2

データ定義ファイル（XML Schema）は、介護標準メッセージを生成する定義文書であり、規定内容そのものである。この XML Schema は、XML のタグ付文書に現れるデータの要素・属性等の定義を行うものであり、実際のデータ連携では、XML Schema で定義した内容をもとに XML を生成し、この XML 形式のファイルをやりとりすることとなる。XML Schema では、連携に必要なすべてのデータを定義することとなるが、業務や制度の変更等に柔軟に対応するために、ある程度メンテナンスを意識した構成に分けることが望ましい。
定義対象である介護保険証情報、居宅サービス計画書情報、サービス提供票情報、予防
サービス計画書情報、予防サービス提供票情報については、XML Schema でそれぞれ下記ファイル名で規定し公開する。
【XML Schema】■介護保険証情報の定義・・・・・・・ファイル名：保険証.xsd■居宅サービス計画書情報の定義・・・ファイル名：計画書.xsd■サービス提供票情報の定義・・・・・ファイル名：提供票.xsd■予防サービス計画書情報の定義・・・ファイル名：予防計画書.xsd■予防サービス提供票情報の定義・・・ファイル名：予防提供票.xsd【目次】
１．介護保険証情報の XML Schema による定・・・・・・・・・・・・・・・・・・13
２．居宅サービス計画書情報の XML Schema による定義・・・・・・・・・・・・・24
３．サービス提供票情報の XML Schema による定義・・・・・・・・・・・・・・・38
４．予防サービス計画書情報の XML Schema による定義・・・・・・・・・・・・・53
５．予防サービス提供票情報の XML Schema による定義・・・・・・・・・・・・・69

3

１． 介護保険証情報の XML Schema による定義「保険証.xsd」ファイルの内容を以下に示す。
<?xml version="1.0" encoding="Shift̲JIS"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"><xsd:element name="Address"><xsd:complexType><xsd:attribute name="city" type="xsd:string" use="optional"/><xsd:attribute name="state" type="xsd:string" use="optional"/><xsd:attribute name="strt" type="xsd:string" use="optional"/><xsd:attribute name="zip" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Agreement"><xsd:complexType/></xsd:element><xsd:element name="Assesment"><xsd:complexType/></xsd:element><xsd:element name="AnotherDivPayMaxMng"><xsd:complexType/></xsd:element><xsd:element name="AnyTime"><xsd:complexType/></xsd:element><xsd:element name="Assd"><xsd:complexType><xsd:sequence><xsd:element ref="Address" minOccurs="0"/><xsd:element ref="Name"/><xsd:element ref="NameKana" minOccurs="0"/><xsd:element ref="HomeCareHist" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="CareFaclHist" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence>4

<xsd:attribute name="Birthday" type="xsd:date" use="optional"/><xsd:attribute name="PhoneNo" type="xsd:string" use="optional"/><xsd:attribute name="Sex" type="ce01" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Assr"><xsd:complexType><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CalcReason" type="xsd:string"/><xsd:element name="CareFaclHist"><xsd:complexType><xsd:attribute name="FaclKind" type="ce06" use="required"/><xsd:attribute name="FaclName" type="xsd:string" use="required"/><xsd:attribute name="InDate" type="xsd:date" use="required"/><xsd:attribute name="OutDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareNec"><xsd:complexType><xsd:sequence><xsd:element ref="PayLimit" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="PayMax" minOccurs="0"/></xsd:sequence><xsd:attribute name="CertDate" type="xsd:date" use="required"/><xsd:attribute name="JudgeNote" type="xsd:string" use="optional"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="Rank" type="ce07" use="required"/></xsd:complexType></xsd:element><xsd:element name="CarePlan"><xsd:complexType/></xsd:element>5

<xsd:element name="CareRankHist̲First"><xsd:complexType/></xsd:element><xsd:element name="CareRankHist̲Recent"><xsd:complexType/></xsd:element><xsd:element name="CareServ"><xsd:complexType/></xsd:element><xsd:element name="CareServComp"><xsd:complexType/></xsd:element><xsd:element name="CheckList"/><xsd:element name="ChgHist̲First"><xsd:complexType/></xsd:element><xsd:element name="ChgHist̲Recent"><xsd:complexType/></xsd:element><xsd:element name="ClsPayMax"><xsd:complexType><xsd:attribute name="ClsBasisPay" type="xsd:float" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="ClsPayMaxMng"><xsd:complexType/></xsd:element><xsd:element name="Communication"><xsd:complexType/></xsd:element><xsd:element name="DailyAct"><xsd:complexType/></xsd:element><xsd:element name="DailyLife"><xsd:complexType/>6</xsd:element><xsd:element name="DailyService̲Plan"><xsd:complexType/></xsd:element><xsd:element name="DailyService̲Result"><xsd:complexType/></xsd:element><xsd:element name="DailyWork"><xsd:complexType/></xsd:element><xsd:element name="Depression"><xsd:complexType/></xsd:element><xsd:element name="DivPayMaxMng"><xsd:complexType/></xsd:element><xsd:element name="Exercise"><xsd:complexType/></xsd:element><xsd:element name="Forget"><xsd:complexType/></xsd:element><xsd:element name="GetInf"><xsd:complexType><xsd:sequence><xsd:element ref="InfSys" minOccurs="0"/><xsd:element ref="Insr"/></xsd:sequence><xsd:attribute name="ID" type="xsd:string" use="required"/><xsd:attribute name="Note" type="xsd:string" use="optional"/><xsd:attribute name="Status" type="ce05" use="required"/></xsd:complexType></xsd:element><xsd:element name="GrantService"><xsd:complexType/></xsd:element>7

<xsd:element name="HcareD"><xsd:complexType/></xsd:element><xsd:element name="HealthManagement"><xsd:complexType/></xsd:element><xsd:element name="Help̲Target"><xsd:complexType/></xsd:element><xsd:element name="HomeCareHist"><xsd:complexType><xsd:attribute name="CorpName" type="xsd:string" use="required"/><xsd:attribute name="RepDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeHelper"><xsd:complexType/></xsd:element><xsd:element name="HomeHelperOffice"><xsd:complexType/></xsd:element><xsd:element name="InfSys"><xsd:complexType><xsd:attribute name="Passwd" type="xsd:string" use="required"/><xsd:attribute name="UserID" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Insr"><xsd:complexType><xsd:sequence><xsd:element ref="Assr" minOccurs="0"/><xsd:element ref="Assd"/><xsd:element ref="CareNec"/></xsd:sequence><xsd:attribute name="Authorized" type="ce02" use="required"/><xsd:attribute name="IssueDate" type="xsd:date" use="optional"/>8

<xsd:attribute name="LimitDate" type="xsd:date" use="optional"/><xsd:attribute name="Num" type="xsd:string" use="optional"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/></xsd:complexType></xsd:element><xsd:element name="LackExercise"><xsd:complexType/></xsd:element><xsd:element name="LifeTarget"><xsd:complexType/></xsd:element><xsd:element name="MsgPack"><xsd:complexType><xsd:sequence><xsd:element ref="GetInf" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType></xsd:element><xsd:element name="Name"><xsd:complexType><xsd:attribute name="fmn" type="xsd:string" use="optional"/><xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="NameKana"><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attribute name="fmn" type="xsd:string" use="optional"/><xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element><xsd:element name="NoGrantService"><xsd:complexType/>9</xsd:element><xsd:element name="Nutrition"><xsd:complexType/></xsd:element><xsd:element name="Oral"><xsd:complexType/></xsd:element><xsd:element name="OwnPayMax"><xsd:complexType/></xsd:element><xsd:element name="PayLimit"><xsd:complexType><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="LimitCont" type="xsd:string" use="required"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="PayMax"><xsd:complexType><xsd:sequence><xsd:element ref="ClsPayMax" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Base" type="xsd:float" use="required"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="Policy"/><xsd:element name="PresentPlan"><xsd:complexType/></xsd:element><xsd:element name="PrevHomeHelperOffice"><xsd:complexType/></xsd:element>

10

<xsd:element name="Prob"><xsd:complexType/></xsd:element><xsd:element name="ProbMeasure"><xsd:complexType/></xsd:element><xsd:element name="PS̲Service"><xsd:complexType/></xsd:element><xsd:element name="PubPay"><xsd:complexType/></xsd:element><xsd:element name="SStyDays"><xsd:complexType/></xsd:element><xsd:element name="TotalPlan"><xsd:complexType/></xsd:element><xsd:element name="Week"><xsd:complexType/></xsd:element><xsd:element name="Withdraw"><xsd:complexType/></xsd:element><xsd:simpleType name="ce01"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="F"/><xsd:enumeration value="M"/><xsd:enumeration value="O"/><xsd:enumeration value="U"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce02"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="Y"/><xsd:enumeration value="N"/>11</xsd:restriction></xsd:simpleType><xsd:simpleType name="ce03"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="SAT"/><xsd:enumeration value="SUN"/><xsd:enumeration value="MON"/><xsd:enumeration value="TUE"/><xsd:enumeration value="WED"/><xsd:enumeration value="THU"/><xsd:enumeration value="FRI"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce05"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="N"/><xsd:enumeration value="D"/><xsd:enumeration value="U"/><xsd:enumeration value="OK"/><xsd:enumeration value="NG"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce06"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="51"/><xsd:enumeration value="52"/><xsd:enumeration value="53"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce07"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="21"/><xsd:enumeration value="22"/>12

<xsd:enumeration value="23"/><xsd:enumeration value="24"/><xsd:enumeration value="25"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce10"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="02"/><xsd:enumeration value="03"/><xsd:enumeration value="04"/><xsd:enumeration value="05"/><xsd:enumeration value="06"/><xsd:enumeration value="07"/><xsd:enumeration value="08"/><xsd:enumeration value="09"/><xsd:enumeration value="10"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="13"/><xsd:enumeration value="99"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce11"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="21"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce12"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/><xsd:enumeration value="2"/><xsd:enumeration value="3"/></xsd:restriction>13

</xsd:simpleType><xsd:simpleType name="ce13"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/><xsd:enumeration value="2"/></xsd:restriction></xsd:simpleType></xsd:schema>

14

２．

居宅サービス計画書情報の XML Schema による定義「計画書.xsd」ファイルの内容を以下に示す。
<?xml version="1.0" encoding="Shift̲JIS"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"><xsd:element name="Address"><xsd:complexType><xsd:attribute name="city" type="xsd:string" use="optional"/><xsd:attribute name="state" type="xsd:string" use="optional"/><xsd:attribute name="strt" type="xsd:string" use="optional"/><xsd:attribute name="zip" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Agreement"><xsd:complexType/></xsd:element><xsd:element name="Assesment"><xsd:complexType/></xsd:element><xsd:element name="AnotherDivPayMaxMng"><xsd:complexType/></xsd:element><xsd:element name="AnyTime"><xsd:complexType><xsd:attribute name="Add" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Assd"><xsd:complexType><xsd:sequence><xsd:element ref="Address" minOccurs="0"/><xsd:element ref="Name"/><xsd:element ref="NameKana" minOccurs="0"/><xsd:element ref="HomeCareHist" minOccurs="0" maxOccurs="unbounded"/>15

<xsd:element ref="CareFaclHist" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Birthday" type="xsd:date" use="optional"/><xsd:attribute name="PhoneNo" type="xsd:string" use="optional"/><xsd:attribute name="Sex" type="ce01" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Assr"><xsd:complexType><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CalcReason"><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attribute name="cd" type="ce12" use="required"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element><xsd:element name="CareFaclHist"><xsd:complexType><xsd:attribute name="FaclKind" type="ce06" use="required"/><xsd:attribute name="FaclName" type="xsd:string" use="required"/><xsd:attribute name="InDate" type="xsd:date" use="required"/><xsd:attribute name="OutDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareNec"><xsd:complexType><xsd:sequence><xsd:element ref="PayLimit" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="PayMax" minOccurs="0"/></xsd:sequence>

16

<xsd:attribute name="CertDate" type="xsd:date" use="required"/><xsd:attribute name="JudgeNote" type="xsd:string" use="optional"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="Rank" type="ce07" use="required"/></xsd:complexType></xsd:element><xsd:element name="CarePlan"><xsd:complexType><xsd:sequence><xsd:element ref="CareServ"/><xsd:element ref="HomeHelperOffice" maxOccurs="unbounded"/><xsd:element ref="CareServComp" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="PS̲Service" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="ID" type="xsd:string" use="required"/><xsd:attribute name="Note" type="xsd:string" use="optional"/><xsd:attribute name="Status" type="ce05" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareRankHist̲First"><xsd:complexType/></xsd:element><xsd:element name="CareRankHist̲Recent"><xsd:complexType/></xsd:element><xsd:element name="CareServ"><xsd:complexType><xsd:sequence><xsd:element ref="CalcReason"/><xsd:element ref="Insr"/><xsd:element ref="ChgHist̲First"/><xsd:element ref="ChgHist̲Recent" minOccurs="0"/><xsd:element ref="DailyAct" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="Help̲Target" maxOccurs="unbounded"/><xsd:element ref="Prob" maxOccurs="unbounded"/>17

<xsd:element ref="HcareD" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Note" type="xsd:string" use="optional"/><xsd:attribute name="refHomeHelper" type="xsd:IDREF" use="required"/><xsd:attribute name="Status" type="ce11" use="required"/><xsd:attribute name="TotalPlan" type="xsd:string" use="required"/><xsd:attribute name="UserReq" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareServComp"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/></xsd:sequence><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="Kind" type="ce10" use="required"/><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/><xsd:attribute name="PhoneNo" type="xsd:string" use="required"/><xsd:attribute name="SatelliteInf" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CheckList"/><xsd:element name="ChgHist̲First"><xsd:complexType><xsd:attribute name="Date" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="ChgHist̲Recent"><xsd:complexType><xsd:attribute name="Date" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="ClsPayMax"><xsd:complexType><xsd:attribute name="ClsBasisPay" type="xsd:float" use="required"/>18

<xsd:attribute name="ServCls" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="ClsPayMaxMng"><xsd:complexType/></xsd:element><xsd:element name="Communication"><xsd:complexType/></xsd:element><xsd:element name="DailyAct"><xsd:complexType><xsd:attribute name="Detail" type="xsd:string" use="required"/><xsd:attribute name="TimeBand.eddt" type="xsd:time" use="optional"/><xsd:attribute name="TimeBand.stdt" type="xsd:time" use="optional"/></xsd:complexType></xsd:element><xsd:element name="DailyLife"><xsd:complexType/></xsd:element><xsd:element name="DailyService̲Plan"><xsd:complexType/></xsd:element><xsd:element name="DailyService̲Result"><xsd:complexType/></xsd:element><xsd:element name="DailyWork"><xsd:complexType><xsd:attribute name="Timeband.eddt" type="xsd:time" use="required"/><xsd:attribute name="Timeband.stdt" type="xsd:time" use="required"/></xsd:complexType></xsd:element><xsd:element name="Depression"><xsd:complexType/></xsd:element><xsd:element name="DivPayMaxMng"><xsd:complexType/>19</xsd:element><xsd:element name="Exercise"><xsd:complexType/></xsd:element><xsd:element name="Forget"><xsd:complexType/></xsd:element><xsd:element name="GetInf"><xsd:complexType/></xsd:element><xsd:element name="GrantService"><xsd:complexType><xsd:attribute name="refPS̲Service" type="xsd:IDREF" use="required"/></xsd:complexType></xsd:element><xsd:element name="HcareD"><xsd:complexType><xsd:sequence><xsd:choice><xsd:element ref="DailyWork" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="Week" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="AnyTime" minOccurs="0" maxOccurs="unbounded"/></xsd:choice><xsd:choice><xsd:element ref="NoGrantService" minOccurs="0"/><xsd:element ref="GrantService" minOccurs="0"/></xsd:choice></xsd:sequence><xsd:attribute name="ClassOL" type="xsd:string" use="required"/><xsd:attribute name="Freq" type="xsd:string" use="required"/><xsd:attribute name="InsrSubj" type="ce02" use="required"/><xsd:attribute name="Outline" type="xsd:string" use="required"/><xsd:attribute name="Period" type="xsd:string" use="required"/><xsd:attribute name="refCareServComp" type="xsd:IDREF" use="optional"/><xsd:attribute name="refHelp̲Target" type="xsd:IDREFS" use="required"/></xsd:complexType>20

</xsd:element><xsd:element name="HealthManagement"><xsd:complexType/></xsd:element><xsd:element name="Help̲Target"><xsd:complexType><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="LongT" type="xsd:string" use="required"/><xsd:attribute name="LTPeriod" type="xsd:string" use="required"/><xsd:attribute name="refProb" type="xsd:IDREFS" use="required"/><xsd:attribute name="ShortT" type="xsd:string" use="required"/><xsd:attribute name="STPeriod" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeCareHist"><xsd:complexType><xsd:attribute name="CorpName" type="xsd:string" use="required"/><xsd:attribute name="RepDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeHelper"><xsd:complexType><xsd:sequence><xsd:element ref="Name"/></xsd:sequence><xsd:attribute name="id" type="xsd:ID" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeHelperOffice"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/><xsd:element ref="HomeHelper" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/>21

<xsd:attribute name="PhoneNo" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="InfSys"><xsd:complexType/></xsd:element><xsd:element name="Insr"><xsd:complexType><xsd:sequence><xsd:element ref="Assr" minOccurs="0"/><xsd:element ref="Assd"/><xsd:element ref="CareNec"/></xsd:sequence><xsd:attribute name="Authorized" type="ce02" use="required"/><xsd:attribute name="IssueDate" type="xsd:date" use="optional"/><xsd:attribute name="LimitDate" type="xsd:date" use="optional"/><xsd:attribute name="Num" type="xsd:string" use="optional"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/></xsd:complexType></xsd:element><xsd:element name="LackExercise"><xsd:complexType/></xsd:element><xsd:element name="LifeTarget"><xsd:complexType/></xsd:element><xsd:element name="MsgPack"><xsd:complexType><xsd:sequence><xsd:element ref="CarePlan" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType></xsd:element><xsd:element name="Name"><xsd:complexType><xsd:attribute name="fmn" type="xsd:string" use="optional"/>22

<xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="NameKana"><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attribute name="fmn" type="xsd:string" use="optional"/><xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element><xsd:element name="NoGrantService"><xsd:complexType><xsd:attribute name="ServCls" type="xsd:string" use="required"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Nutrition"><xsd:complexType/></xsd:element><xsd:element name="Oral"><xsd:complexType/></xsd:element><xsd:element name="OwnPayMax"><xsd:complexType/></xsd:element><xsd:element name="PayLimit"><xsd:complexType><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="LimitCont" type="xsd:string" use="required"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/></xsd:complexType>23

</xsd:element><xsd:element name="PayMax"><xsd:complexType><xsd:sequence><xsd:element ref="ClsPayMax" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Base" type="xsd:float" use="required"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="Policy"/><xsd:element name="PresentPlan"><xsd:complexType/></xsd:element><xsd:element name="PrevHomeHelperOffice"><xsd:complexType/></xsd:element><xsd:element name="Prob"><xsd:complexType><xsd:attribute name="Detail" type="xsd:string" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/></xsd:complexType></xsd:element><xsd:element name="ProbMeasure"><xsd:complexType/></xsd:element><xsd:element name="PS̲Service"><xsd:complexType><xsd:attribute name="ClsPayMaxSubj" type="ce02" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/><xsd:attribute name="UnitNum" type="xsd:float" use="required"/><xsd:attribute name="UnitPrice" type="xsd:float" use="required"/></xsd:complexType>24

</xsd:element><xsd:element name="PubPay"><xsd:complexType/></xsd:element><xsd:element name="SStyDays"><xsd:complexType/></xsd:element><xsd:element name="TotalPlan"><xsd:complexType/></xsd:element><xsd:element name="Week"><xsd:complexType><xsd:attribute name="Day" type="ce03" use="required"/><xsd:attribute name="Timeband.eddt" type="xsd:time" use="required"/><xsd:attribute name="Timeband.stdt" type="xsd:time" use="required"/></xsd:complexType></xsd:element><xsd:element name="Withdraw"><xsd:complexType/></xsd:element><xsd:simpleType name="ce01"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="F"/><xsd:enumeration value="M"/><xsd:enumeration value="O"/><xsd:enumeration value="U"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce02"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="Y"/><xsd:enumeration value="N"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce03"><xsd:restriction base="xsd:NMTOKEN">25

<xsd:enumeration value="SAT"/><xsd:enumeration value="SUN"/><xsd:enumeration value="MON"/><xsd:enumeration value="TUE"/><xsd:enumeration value="WED"/><xsd:enumeration value="THU"/><xsd:enumeration value="FRI"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce05"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="N"/><xsd:enumeration value="D"/><xsd:enumeration value="U"/><xsd:enumeration value="OK"/><xsd:enumeration value="NG"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce06"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="51"/><xsd:enumeration value="52"/><xsd:enumeration value="53"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce07"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="21"/><xsd:enumeration value="22"/><xsd:enumeration value="23"/><xsd:enumeration value="24"/><xsd:enumeration value="25"/></xsd:restriction>26

</xsd:simpleType><xsd:simpleType name="ce10"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="02"/><xsd:enumeration value="03"/><xsd:enumeration value="04"/><xsd:enumeration value="05"/><xsd:enumeration value="06"/><xsd:enumeration value="07"/><xsd:enumeration value="08"/><xsd:enumeration value="09"/><xsd:enumeration value="10"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="13"/><xsd:enumeration value="99"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce11"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="21"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce12"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/><xsd:enumeration value="2"/><xsd:enumeration value="3"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce13"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/>27

<xsd:enumeration value="2"/></xsd:restriction></xsd:simpleType></xsd:schema>

28

３．

サービス提供票情報の XML Schema による定義「提供票.xsd」ファイルの内容を以下に示す。
<?xml version="1.0" encoding="Shift̲JIS"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"><xsd:element name="Address"><xsd:complexType><xsd:attribute name="city" type="xsd:string" use="optional"/><xsd:attribute name="state" type="xsd:string" use="optional"/><xsd:attribute name="strt" type="xsd:string" use="optional"/><xsd:attribute name="zip" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Agreement"><xsd:complexType/></xsd:element><xsd:element name="Assesment"><xsd:complexType/></xsd:element><xsd:element name="AnotherDivPayMaxMng"><xsd:complexType><xsd:attribute name="AllOwnPay" type="xsd:float" use="required"/><xsd:attribute name="ClsLimFixU" type="xsd:float" use="required"/><xsd:attribute name="ClsLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="DivLimFixU" type="xsd:float" use="required"/><xsd:attribute name="DivLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="InsOwnPay" type="xsd:float" use="required"/><xsd:attribute name="InsPay" type="xsd:float" use="required"/><xsd:attribute name="InsTotal" type="xsd:float" use="required"/><xsd:attribute name="ServUnit" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="AnyTime"><xsd:complexType/>29</xsd:element><xsd:element name="Assd"><xsd:complexType><xsd:sequence><xsd:element ref="Address" minOccurs="0"/><xsd:element ref="Name"/><xsd:element ref="NameKana" minOccurs="0"/><xsd:element ref="HomeCareHist" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="CareFaclHist" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Birthday" type="xsd:date" use="optional"/><xsd:attribute name="PhoneNo" type="xsd:string" use="optional"/><xsd:attribute name="Sex" type="ce01" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Assr"><xsd:complexType><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CalcReason" type="xsd:string"/><xsd:element name="CareFaclHist"><xsd:complexType><xsd:attribute name="FaclKind" type="ce06" use="required"/><xsd:attribute name="FaclName" type="xsd:string" use="required"/><xsd:attribute name="InDate" type="xsd:date" use="required"/><xsd:attribute name="OutDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareNec"><xsd:complexType><xsd:sequence><xsd:element ref="PayLimit" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="PayMax" minOccurs="0"/></xsd:sequence>30

<xsd:attribute name="CertDate" type="xsd:date" use="required"/><xsd:attribute name="JudgeNote" type="xsd:string" use="optional"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="Rank" type="ce07" use="required"/></xsd:complexType></xsd:element><xsd:element name="CarePlan"><xsd:complexType><xsd:sequence><xsd:element ref="CareServ"/><xsd:element ref="HomeHelperOffice" maxOccurs="unbounded"/><xsd:element ref="CareServComp" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="PS̲Service" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="ID" type="xsd:string" use="required"/><xsd:attribute name="Note" type="xsd:string" use="optional"/><xsd:attribute name="Status" type="ce05" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareRankHist̲First"><xsd:complexType><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="Rank" type="ce07" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareRankHist̲Recent"><xsd:complexType><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="Rank" type="ce07" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareServ"><xsd:complexType><xsd:sequence><xsd:element ref="Insr"/>

31

<xsd:element ref="DivPayMaxMng" minOccurs="0"/><xsd:element ref="AnotherDivPayMaxMng" minOccurs="0"/><xsd:element ref="SStyDays" minOccurs="0"/><xsd:choice><xsd:element ref="PubPay" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="OwnPayMax" minOccurs="0" maxOccurs="unbounded"/></xsd:choice><xsd:element ref="CareRankHist̲First"/><xsd:element ref="CareRankHist̲Recent" minOccurs="0"/><xsd:element ref="HcareD" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="AssrConf" type="xsd:string" use="optional"/><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="MDate" type="xsd:date" use="optional"/><xsd:attribute name="Note" type="xsd:string" use="optional"/><xsd:attribute name="refHomeHelper" type="xsd:IDREF" use="required"/><xsd:attribute name="RepDate" type="xsd:date" use="optional"/></xsd:complexType></xsd:element><xsd:element name="CareServComp"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/></xsd:sequence><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="Kind" type="ce10" use="required"/><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/><xsd:attribute name="PhoneNo" type="xsd:string" use="required"/><xsd:attribute name="SatelliteInf" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CheckList"/><xsd:element name="ChgHist̲First"><xsd:complexType/></xsd:element>

32<xsd:element name="ChgHist̲Recent"><xsd:complexType/></xsd:element><xsd:element name="ClsPayMax"><xsd:complexType><xsd:attribute name="ClsBasisPay" type="xsd:float" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="ClsPayMaxMng"><xsd:complexType><xsd:attribute name="AllOwnPay" type="xsd:float" use="required"/><xsd:attribute name="ClsLimFixU" type="xsd:float" use="required"/><xsd:attribute name="ClsLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="ClsPayMaxSubj" type="ce02" use="required"/><xsd:attribute name="DivLimFixU" type="xsd:float" use="required"/><xsd:attribute name="DivLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="InsOwnPay" type="xsd:float" use="required"/><xsd:attribute name="InsPay" type="xsd:float" use="required"/><xsd:attribute name="InsTotal" type="xsd:float" use="required"/><xsd:attribute name="LimOvrUnit" type="xsd:float" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/><xsd:attribute name="ServUnit" type="xsd:float" use="required"/><xsd:attribute name="TokuchiSubj" type="ce02" use="required"/><xsd:attribute name="TotalUnit" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="Communication"><xsd:complexType/></xsd:element><xsd:element name="DailyAct"><xsd:complexType/></xsd:element><xsd:element name="DailyLife"><xsd:complexType/></xsd:element>33

<xsd:element name="DailyService̲Plan"><xsd:complexType><xsd:attribute name="Count" type="xsd:float" use="required"/><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="DayW" type="ce03" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="TimeScale.eddt" type="xsd:time" use="optional"/><xsd:attribute name="TimeScale.stdt" type="xsd:time" use="optional"/></xsd:complexType></xsd:element><xsd:element name="DailyService̲Result"><xsd:complexType><xsd:attribute name="Count" type="xsd:float" use="required"/><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="DayW" type="ce03" use="required"/><xsd:attribute name="refPlan" type="xsd:IDREFS" use="optional"/><xsd:attribute name="TimeScale.eddt" type="xsd:time" use="optional"/><xsd:attribute name="TimeScale.stdt" type="xsd:time" use="optional"/></xsd:complexType></xsd:element><xsd:element name="DailyWork"><xsd:complexType/></xsd:element><xsd:element name="Depression"><xsd:complexType/></xsd:element><xsd:element name="DivPayMaxMng"><xsd:complexType><xsd:sequence><xsd:element ref="ClsPayMaxMng" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="AllOwnPay" type="xsd:float" use="required"/><xsd:attribute name="ClsLimFixU" type="xsd:float" use="required"/><xsd:attribute name="ClsLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="DivLimFixU" type="xsd:float" use="required"/><xsd:attribute name="DivLimOvrU" type="xsd:float" use="required"/>34

<xsd:attribute name="InsOwnPay" type="xsd:float" use="required"/><xsd:attribute name="InsPay" type="xsd:float" use="required"/><xsd:attribute name="InsTotal" type="xsd:float" use="required"/><xsd:attribute name="ServUnit" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="Exercise"><xsd:complexType/></xsd:element><xsd:element name="Forget"><xsd:complexType/></xsd:element><xsd:element name="GetInf"><xsd:complexType/></xsd:element><xsd:element name="GrantService"><xsd:complexType><xsd:attribute name="refPS̲Service" type="xsd:IDREF" use="required"/></xsd:complexType></xsd:element><xsd:element name="HcareD"><xsd:complexType><xsd:sequence><xsd:element ref="DailyService̲Plan" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="DailyService̲Result" minOccurs="0" maxOccurs="unbounded"/><xsd:choice><xsd:element ref="NoGrantService" minOccurs="0"/><xsd:element ref="GrantService" minOccurs="0"/></xsd:choice></xsd:sequence><xsd:attribute name="DisUnit" type="xsd:float" use="required"/><xsd:attribute name="InsrSubj" type="ce02" use="required"/><xsd:attribute name="Percent" type="xsd:float" use="required"/><xsd:attribute name="PlanTotal" type="xsd:float" use="required"/><xsd:attribute name="refCareServComp" type="xsd:IDREF" use="optional"/><xsd:attribute name="ResultTotal" type="xsd:float" use="required"/>35

</xsd:complexType></xsd:element><xsd:element name="HealthManagement"><xsd:complexType/></xsd:element><xsd:element name="Help̲Target"><xsd:complexType/></xsd:element><xsd:element name="HomeCareHist"><xsd:complexType><xsd:attribute name="CorpName" type="xsd:string" use="required"/><xsd:attribute name="RepDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeHelper"><xsd:complexType><xsd:sequence><xsd:element ref="Name"/></xsd:sequence><xsd:attribute name="id" type="xsd:ID" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeHelperOffice"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/><xsd:element ref="HomeHelper" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/><xsd:attribute name="PhoneNo" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="InfSys"><xsd:complexType/></xsd:element>36

<xsd:element name="Insr"><xsd:complexType><xsd:sequence><xsd:element ref="Assr" minOccurs="0"/><xsd:element ref="Assd"/><xsd:element ref="CareNec"/></xsd:sequence><xsd:attribute name="Authorized" type="ce02" use="required"/><xsd:attribute name="IssueDate" type="xsd:date" use="optional"/><xsd:attribute name="LimitDate" type="xsd:date" use="optional"/><xsd:attribute name="Num" type="xsd:string" use="optional"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/></xsd:complexType></xsd:element><xsd:element name="LackExercise"><xsd:complexType/></xsd:element><xsd:element name="LifeTarget"><xsd:complexType/></xsd:element><xsd:element name="MsgPack"><xsd:complexType><xsd:sequence><xsd:element ref="CarePlan" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType></xsd:element><xsd:element name="Name"><xsd:complexType><xsd:attribute name="fmn" type="xsd:string" use="optional"/><xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="NameKana"><xsd:complexType><xsd:simpleContent>37

<xsd:extension base="xsd:string"><xsd:attribute name="fmn" type="xsd:string" use="optional"/><xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element><xsd:element name="NoGrantService"><xsd:complexType><xsd:attribute name="ServCls" type="xsd:string" use="required"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Nutrition"><xsd:complexType/></xsd:element><xsd:element name="Oral"><xsd:complexType/></xsd:element><xsd:element name="OwnPayMax"><xsd:complexType><xsd:attribute name="Detail" type="xsd:string" use="required"/><xsd:attribute name="PayMax" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="PayLimit"><xsd:complexType><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="LimitCont" type="xsd:string" use="required"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="PayMax"><xsd:complexType>38

<xsd:sequence><xsd:element ref="ClsPayMax" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Base" type="xsd:float" use="required"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="Policy"/><xsd:element name="PresentPlan"><xsd:complexType/></xsd:element><xsd:element name="PrevHomeHelperOffice"><xsd:complexType/></xsd:element><xsd:element name="Prob"><xsd:complexType/></xsd:element><xsd:element name="ProbMeasure"><xsd:complexType/></xsd:element><xsd:element name="PS̲Service"><xsd:complexType><xsd:attribute name="ClsPayMaxSubj" type="ce02" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/><xsd:attribute name="UnitNum" type="xsd:float" use="required"/><xsd:attribute name="UnitPrice" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="PubPay"><xsd:complexType><xsd:attribute name="BeneficiaryNo" type="xsd:string" use="optional"/><xsd:attribute name="Cls" type="xsd:string" use="required"/><xsd:attribute name="IssueDate" type="xsd:date" use="optional"/>39<xsd:attribute name="LifeTime.eddt" type="xsd:date" use="optional"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="optional"/><xsd:attribute name="PayName" type="xsd:string" use="optional"/><xsd:attribute name="PayNo" type="xsd:string" use="optional"/><xsd:attribute name="Percent" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="SStyDays"><xsd:complexType><xsd:attribute name="LstMonthUseDays" type="xsd:float" use="required"/><xsd:attribute name="SumUseDays" type="xsd:float" use="required"/><xsd:attribute name="ThisMonthPlanUseDays" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="TotalPlan"><xsd:complexType/></xsd:element><xsd:element name="Week"><xsd:complexType/></xsd:element><xsd:element name="Withdraw"><xsd:complexType/></xsd:element><xsd:simpleType name="ce01"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="F"/><xsd:enumeration value="M"/><xsd:enumeration value="O"/><xsd:enumeration value="U"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce02"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="Y"/><xsd:enumeration value="N"/></xsd:restriction>40</xsd:simpleType><xsd:simpleType name="ce03"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="SAT"/><xsd:enumeration value="SUN"/><xsd:enumeration value="MON"/><xsd:enumeration value="TUE"/><xsd:enumeration value="WED"/><xsd:enumeration value="THU"/><xsd:enumeration value="FRI"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce05"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="N"/><xsd:enumeration value="D"/><xsd:enumeration value="U"/><xsd:enumeration value="OK"/><xsd:enumeration value="NG"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce06"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="51"/><xsd:enumeration value="52"/><xsd:enumeration value="53"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce07"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="21"/><xsd:enumeration value="22"/><xsd:enumeration value="23"/>41

<xsd:enumeration value="24"/><xsd:enumeration value="25"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce10"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="02"/><xsd:enumeration value="03"/><xsd:enumeration value="04"/><xsd:enumeration value="05"/><xsd:enumeration value="06"/><xsd:enumeration value="07"/><xsd:enumeration value="08"/><xsd:enumeration value="09"/><xsd:enumeration value="10"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="13"/><xsd:enumeration value="99"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce11"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="21"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce12"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/><xsd:enumeration value="2"/><xsd:enumeration value="3"/></xsd:restriction></xsd:simpleType>42

<xsd:simpleType name="ce13"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/><xsd:enumeration value="2"/></xsd:restriction></xsd:simpleType></xsd:schema>

43

４．

予防サービス計画書情報の XML Schema による定義「予防計画書.xsd」ファイルの内容を以下に示す。
<?xml version="1.0" encoding="Shift̲JIS"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"><xsd:element name="Address"><xsd:complexType><xsd:attribute name="city" type="xsd:string" use="optional"/><xsd:attribute name="state" type="xsd:string" use="optional"/><xsd:attribute name="strt" type="xsd:string" use="optional"/><xsd:attribute name="zip" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Agreement"><xsd:complexType><xsd:attribute name="Date" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Assesment"><xsd:complexType><xsd:sequence><xsd:element ref="Exercise" maxOccurs="unbounded"/><xsd:element ref="DailyLife" maxOccurs="unbounded"/><xsd:element ref="Communication" maxOccurs="unbounded"/><xsd:element ref="HealthManagement" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Attention" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="AnotherDivPayMaxMng"><xsd:complexType/></xsd:element><xsd:element name="AnyTime"><xsd:complexType>44

<xsd:attribute name="Add" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Assd"><xsd:complexType><xsd:sequence><xsd:element ref="Address" minOccurs="0"/><xsd:element ref="Name"/><xsd:element ref="NameKana" minOccurs="0"/><xsd:element ref="HomeCareHist" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="CareFaclHist" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="age" type="xsd:float" use="optional"/><xsd:attribute name="Birthday" type="xsd:date" use="optional"/><xsd:attribute name="PhoneNo" type="xsd:string" use="optional"/><xsd:attribute name="Sex" type="ce01" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Assr"><xsd:complexType><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CalcReason" type="xsd:string"/><xsd:element name="CareFaclHist"><xsd:complexType><xsd:attribute name="FaclKind" type="ce06" use="required"/><xsd:attribute name="FaclName" type="xsd:string" use="required"/><xsd:attribute name="InDate" type="xsd:date" use="required"/><xsd:attribute name="OutDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareNec"><xsd:complexType><xsd:sequence>45

<xsd:element ref="PayLimit" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="PayMax" minOccurs="0"/></xsd:sequence><xsd:attribute name="CertDate" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="Rank" type="ce07" use="required"/></xsd:complexType></xsd:element><xsd:element name="CarePlan"><xsd:complexType><xsd:sequence><xsd:element ref="CareServ"/><xsd:element ref="PrevHomeHelperOffice" maxOccurs="unbounded"/><xsd:element ref="HomeHelperOffice" maxOccurs="unbounded"/><xsd:element ref="CareServComp" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="PS̲Service" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="ID" type="xsd:string" use="required"/><xsd:attribute name="Note" type="xsd:string" use="optional"/><xsd:attribute name="Status" type="ce05" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareRankHist̲First"><xsd:complexType/></xsd:element><xsd:element name="CareRankHist̲Recent"><xsd:complexType/></xsd:element><xsd:element name="CareServ"><xsd:complexType><xsd:sequence><xsd:element ref="Insr"/><xsd:element ref="ChgHist̲First"/><xsd:element ref="ChgHist̲Recent" minOccurs="0"/><xsd:element ref="Assesment" maxOccurs="unbounded"/>46

<xsd:element ref="ProbMeasure" maxOccurs="unbounded"/><xsd:element ref="Policy" maxOccurs="unbounded"/><xsd:element ref="HcareD" maxOccurs="unbounded"/><xsd:element ref="Agreement"/><xsd:element ref="CheckList"/><xsd:element ref="DailyAct" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="No" type="xsd:string" use="required"/><xsd:attribute name="Note" type="xsd:string" use="optional"/><xsd:attribute name="refHomeHelper" type="xsd:IDREF" use="required"/><xsd:attribute name="Status" type="ce11" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareServComp"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/></xsd:sequence><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="Kind" type="ce10" use="required"/><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/><xsd:attribute name="PhoneNo" type="xsd:string" use="required"/><xsd:attribute name="SatelliteInf" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CheckList"><xsd:complexType><xsd:sequence><xsd:element ref="LackExercise"/><xsd:element ref="Nutrition"/><xsd:element ref="Oral"/><xsd:element ref="Withdraw"/><xsd:element ref="Forget"/><xsd:element ref="Depression"/></xsd:sequence>47</xsd:complexType></xsd:element><xsd:element name="ChgHist̲First"><xsd:complexType><xsd:attribute name="Date" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="ChgHist̲Recent"><xsd:complexType><xsd:attribute name="Date" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="ClsPayMax"><xsd:complexType><xsd:attribute name="ClsBasisPay" type="xsd:float" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="ClsPayMaxMng"><xsd:complexType/></xsd:element><xsd:element name="Communication"><xsd:complexType><xsd:attribute name="Check" type="ce13" use="required"/><xsd:attribute name="Condition" type="xsd:string" use="required"/><xsd:attribute name="Prob" type="xsd:string" use="required"/><xsd:attribute name="UserReq" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="DailyAct"><xsd:complexType><xsd:attribute name="Detail" type="xsd:string" use="required"/><xsd:attribute name="TimeBand.eddt" type="xsd:time" use="optional"/><xsd:attribute name="TimeBand.stdt" type="xsd:time" use="optional"/></xsd:complexType></xsd:element>48

<xsd:element name="DailyLife"><xsd:complexType><xsd:attribute name="Check" type="ce13" use="required"/><xsd:attribute name="Condition" type="xsd:string" use="required"/><xsd:attribute name="Prob" type="xsd:string" use="required"/><xsd:attribute name="UserReq" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="DailyService̲Plan"><xsd:complexType/></xsd:element><xsd:element name="DailyService̲Result"><xsd:complexType/></xsd:element><xsd:element name="DailyWork"><xsd:complexType><xsd:attribute name="Timeband.eddt" type="xsd:time" use="required"/><xsd:attribute name="Timeband.stdt" type="xsd:time" use="required"/></xsd:complexType></xsd:element><xsd:element name="Depression"><xsd:complexType><xsd:attribute name="Question" type="xsd:float" use="required"/><xsd:attribute name="TotalQuestion" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="DivPayMaxMng"><xsd:complexType/></xsd:element><xsd:element name="Exercise"><xsd:complexType><xsd:attribute name="Check" type="ce13" use="required"/><xsd:attribute name="Condition" type="xsd:string" use="required"/><xsd:attribute name="Prob" type="xsd:string" use="required"/><xsd:attribute name="UserReq" type="xsd:string" use="required"/></xsd:complexType>49

</xsd:element><xsd:element name="Forget"><xsd:complexType><xsd:attribute name="Question" type="xsd:float" use="required"/><xsd:attribute name="TotalQuestion" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="GetInf"><xsd:complexType/></xsd:element><xsd:element name="GrantService"><xsd:complexType><xsd:attribute name="refPS̲Service" type="xsd:IDREF" use="required"/></xsd:complexType></xsd:element><xsd:element name="HcareD"><xsd:complexType><xsd:sequence><xsd:element ref="Target" maxOccurs="unbounded"/><xsd:element ref="Point" maxOccurs="unbounded"/><xsd:element ref="SupportPlan" maxOccurs="unbounded"/><xsd:element ref="ServKind" maxOccurs="unbounded"/><xsd:choice><xsd:element ref="DailyWork" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="Week" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="AnyTime" minOccurs="0" maxOccurs="unbounded"/></xsd:choice><xsd:choice><xsd:element ref="NoGrantService" minOccurs="0"/><xsd:element ref="GrantService" minOccurs="0"/></xsd:choice></xsd:sequence></xsd:complexType></xsd:element><xsd:element name="HealthManagement"><xsd:complexType>50

<xsd:attribute name="Check" type="ce13" use="required"/><xsd:attribute name="Condition" type="xsd:string" use="required"/><xsd:attribute name="Prob" type="xsd:string" use="required"/><xsd:attribute name="UserReq" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Help̲Target"><xsd:complexType/></xsd:element><xsd:element name="HomeCareHist"><xsd:complexType><xsd:attribute name="CorpName" type="xsd:string" use="required"/><xsd:attribute name="RepDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeHelper"><xsd:complexType><xsd:sequence><xsd:element ref="Name"/></xsd:sequence><xsd:attribute name="id" type="xsd:ID" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeHelperOffice"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/><xsd:element ref="HomeHelper" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/><xsd:attribute name="PhoneNo" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="InfSys"><xsd:complexType/>51</xsd:element><xsd:element name="Insr"><xsd:complexType><xsd:sequence><xsd:element ref="Assr" minOccurs="0"/><xsd:element ref="Assd"/><xsd:element ref="CareNec"/></xsd:sequence><xsd:attribute name="Authorized" type="ce02" use="required"/><xsd:attribute name="IssueDate" type="xsd:date" use="optional"/><xsd:attribute name="LimitDate" type="xsd:date" use="optional"/><xsd:attribute name="Num" type="xsd:string" use="optional"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/></xsd:complexType></xsd:element><xsd:element name="LackExercise"><xsd:complexType><xsd:attribute name="Question" type="xsd:float" use="required"/><xsd:attribute name="TotalQuestion" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="LifeTarget"><xsd:complexType><xsd:attribute name="DayTarget" type="xsd:string" use="required"/><xsd:attribute name="YearTarget" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="MsgPack"><xsd:complexType><xsd:sequence><xsd:element ref="CarePlan" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType></xsd:element><xsd:element name="Name"><xsd:complexType>52

<xsd:attribute name="fmn" type="xsd:string" use="optional"/><xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="NameKana"><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attribute name="fmn" type="xsd:string" use="optional"/><xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element><xsd:element name="NoGrantService"><xsd:complexType><xsd:attribute name="ServCls" type="xsd:string" use="required"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Nutrition"><xsd:complexType><xsd:attribute name="Question" type="xsd:float" use="required"/><xsd:attribute name="TotalQuestion" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="Oral"><xsd:complexType><xsd:attribute name="Question" type="xsd:float" use="required"/><xsd:attribute name="TotalQuestion" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="OwnPayMax"><xsd:complexType/></xsd:element><xsd:element name="PayLimit">53

<xsd:complexType><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="LimitCont" type="xsd:string" use="required"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="PayMax"><xsd:complexType><xsd:sequence><xsd:element ref="ClsPayMax" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Base" type="xsd:float" use="required"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="Point"><xsd:complexType><xsd:attribute name="Detail" type="xsd:string" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="refTarget" type="xsd:IDREFS" use="required"/></xsd:complexType></xsd:element><xsd:element name="Policy"><xsd:complexType><xsd:sequence><xsd:element ref="LifeTarget"/><xsd:element ref="TotalPlan"/><xsd:element ref="PresentPlan" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType></xsd:element><xsd:element name="PresentPlan"><xsd:complexType>54

<xsd:attribute name="Detail" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="PrevHomeHelperOffice"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/><xsd:element ref="HomeHelper" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Comment" type="xsd:string"/><xsd:attribute name="Num" type="xsd:string" use="required"/><xsd:attribute name="PhoneNo" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Prob"><xsd:complexType/></xsd:element><xsd:element name="ProbMeasure"><xsd:complexType><xsd:attribute name="TargetMeasure" type="xsd:string" use="required"/><xsd:attribute name="TotalProb" type="xsd:string" use="required"/><xsd:attribute name="UserReq" type="xsd:string" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/></xsd:complexType></xsd:element><xsd:element name="PS̲Service"><xsd:complexType><xsd:attribute name="ClsPayMaxSubj" type="ce02" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/><xsd:attribute name="UnitNum" type="xsd:float" use="required"/><xsd:attribute name="UnitPrice" type="xsd:float" use="required"/></xsd:complexType></xsd:element>55

<xsd:element name="PubPay"><xsd:complexType/></xsd:element><xsd:element name="ServKind"><xsd:complexType><xsd:attribute name="ClassOL" type="xsd:string" use="required"/><xsd:attribute name="Period" type="xsd:string" use="required"/><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="refSupportPlan" type="xsd:IDREFS" use="required"/><xsd:attribute name="refCareServComp" type="xsd:IDREF" use="optional"/></xsd:complexType></xsd:element><xsd:element name="SStyDays"><xsd:complexType/></xsd:element><xsd:element name="SupportPlan"><xsd:complexType><xsd:attribute name="OtherSupport" type="xsd:string" use="required"/><xsd:attribute name="Outline" type="xsd:string" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="refPoint" type="xsd:IDREFS" use="required"/></xsd:complexType></xsd:element><xsd:element name="Target"><xsd:complexType><xsd:attribute name="Detail" type="xsd:string" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="refProbMeasure" type="xsd:IDREFS" use="required"/></xsd:complexType></xsd:element><xsd:element name="TotalPlan"><xsd:complexType><xsd:attribute name="Detail" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Week">

56

<xsd:complexType><xsd:attribute name="Day" type="ce03" use="required"/><xsd:attribute name="Timeband.eddt" type="xsd:time" use="required"/><xsd:attribute name="Timeband.stdt" type="xsd:time" use="required"/></xsd:complexType></xsd:element><xsd:element name="Withdraw"><xsd:complexType><xsd:attribute name="Question" type="xsd:float" use="required"/><xsd:attribute name="TotalQuestion" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:simpleType name="ce01"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="F"/><xsd:enumeration value="M"/><xsd:enumeration value="O"/><xsd:enumeration value="U"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce02"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="Y"/><xsd:enumeration value="N"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce03"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="SAT"/><xsd:enumeration value="SUN"/><xsd:enumeration value="MON"/><xsd:enumeration value="TUE"/><xsd:enumeration value="WED"/><xsd:enumeration value="THU"/><xsd:enumeration value="FRI"/></xsd:restriction>57

</xsd:simpleType><xsd:simpleType name="ce05"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="N"/><xsd:enumeration value="D"/><xsd:enumeration value="U"/><xsd:enumeration value="OK"/><xsd:enumeration value="NG"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce06"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="51"/><xsd:enumeration value="52"/><xsd:enumeration value="53"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce07"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="21"/><xsd:enumeration value="22"/><xsd:enumeration value="23"/><xsd:enumeration value="24"/><xsd:enumeration value="25"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce10"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="02"/><xsd:enumeration value="03"/><xsd:enumeration value="04"/><xsd:enumeration value="05"/>58

<xsd:enumeration value="06"/><xsd:enumeration value="07"/><xsd:enumeration value="08"/><xsd:enumeration value="09"/><xsd:enumeration value="10"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="13"/><xsd:enumeration value="99"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce11"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="21"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce12"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/><xsd:enumeration value="2"/><xsd:enumeration value="3"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce13"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/><xsd:enumeration value="2"/></xsd:restriction></xsd:simpleType></xsd:schema>

59

５．

予防サービス提供票情報の XML Schema による定義「予防提供票.xsd」ファイルの内容を以下に示す。
<?xml version="1.0" encoding="Shift̲JIS"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"><xsd:element name="Address"><xsd:complexType><xsd:attribute name="city" type="xsd:string" use="optional"/><xsd:attribute name="state" type="xsd:string" use="optional"/><xsd:attribute name="strt" type="xsd:string" use="optional"/><xsd:attribute name="zip" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Agreement"><xsd:complexType/></xsd:element><xsd:element name="Assesment"><xsd:complexType/></xsd:element><xsd:element name="AnotherDivPayMaxMng"><xsd:complexType><xsd:attribute name="AllOwnPay" type="xsd:float" use="required"/><xsd:attribute name="ClsLimFixU" type="xsd:float" use="required"/><xsd:attribute name="ClsLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="DivLimFixU" type="xsd:float" use="required"/><xsd:attribute name="DivLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="InsOwnPay" type="xsd:float" use="required"/><xsd:attribute name="InsPay" type="xsd:float" use="required"/><xsd:attribute name="InsTotal" type="xsd:float" use="required"/><xsd:attribute name="ServUnit" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="AnyTime">

60

<xsd:complexType/></xsd:element><xsd:element name="Assd"><xsd:complexType><xsd:sequence><xsd:element ref="Address" minOccurs="0"/><xsd:element ref="Name"/><xsd:element ref="NameKana" minOccurs="0"/><xsd:element ref="HomeCareHist" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="CareFaclHist" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Birthday" type="xsd:date" use="optional"/><xsd:attribute name="PhoneNo" type="xsd:string" use="optional"/><xsd:attribute name="Sex" type="ce01" use="optional"/></xsd:complexType></xsd:element><xsd:element name="Assr"><xsd:complexType><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CalcReason" type="xsd:string"/><xsd:element name="CareFaclHist"><xsd:complexType><xsd:attribute name="FaclKind" type="ce06" use="required"/><xsd:attribute name="FaclName" type="xsd:string" use="required"/><xsd:attribute name="InDate" type="xsd:date" use="required"/><xsd:attribute name="OutDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareNec"><xsd:complexType><xsd:sequence><xsd:element ref="PayLimit" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="PayMax" minOccurs="0"/>61</xsd:sequence><xsd:attribute name="CertDate" type="xsd:date" use="required"/><xsd:attribute name="JudgeNote" type="xsd:string" use="optional"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="Rank" type="ce07" use="required"/></xsd:complexType></xsd:element><xsd:element name="CarePlan"><xsd:complexType><xsd:sequence><xsd:element ref="CareServ"/><xsd:element ref="HomeHelperOffice" maxOccurs="unbounded"/><xsd:element ref="PrevHomeHelperOffice" maxOccurs="unbounded"/><xsd:element ref="CareServComp" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="PS̲Service" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="ID" type="xsd:string" use="required"/><xsd:attribute name="Note" type="xsd:string" use="optional"/><xsd:attribute name="Status" type="ce05" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareRankHist̲First"><xsd:complexType><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="Rank" type="ce07" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareRankHist̲Recent"><xsd:complexType><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="Rank" type="ce07" use="required"/></xsd:complexType></xsd:element><xsd:element name="CareServ"><xsd:complexType>62

<xsd:sequence><xsd:element ref="Insr"/><xsd:element ref="DivPayMaxMng" minOccurs="0"/><xsd:element ref="AnotherDivPayMaxMng" minOccurs="0"/><xsd:element ref="SStyDays" minOccurs="0"/><xsd:choice><xsd:element ref="PubPay" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="OwnPayMax" minOccurs="0" maxOccurs="unbounded"/></xsd:choice><xsd:element ref="CareRankHist̲First"/><xsd:element ref="CareRankHist̲Recent" minOccurs="0"/><xsd:element ref="HcareD" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="AssrConf" type="xsd:string" use="optional"/><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="MDate" type="xsd:date" use="optional"/><xsd:attribute name="Note" type="xsd:string" use="optional"/><xsd:attribute name="refHomeHelper" type="xsd:IDREF" use="required"/><xsd:attribute name="RepDate" type="xsd:date" use="optional"/></xsd:complexType></xsd:element><xsd:element name="CareServComp"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/></xsd:sequence><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="Kind" type="ce10" use="required"/><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/><xsd:attribute name="PhoneNo" type="xsd:string" use="required"/><xsd:attribute name="SatelliteInf" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="CheckList"/><xsd:element name="ChgHist̲First">

63

<xsd:complexType/></xsd:element><xsd:element name="ChgHist̲Recent"><xsd:complexType/></xsd:element><xsd:element name="ClsPayMax"><xsd:complexType><xsd:attribute name="ClsBasisPay" type="xsd:float" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="ClsPayMaxMng"><xsd:complexType><xsd:attribute name="AllOwnPay" type="xsd:float" use="required"/><xsd:attribute name="ClsLimFixU" type="xsd:float" use="required"/><xsd:attribute name="ClsLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="ClsPayMaxSubj" type="ce02" use="required"/><xsd:attribute name="DivLimFixU" type="xsd:float" use="required"/><xsd:attribute name="DivLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="InsOwnPay" type="xsd:float" use="required"/><xsd:attribute name="InsPay" type="xsd:float" use="required"/><xsd:attribute name="InsTotal" type="xsd:float" use="required"/><xsd:attribute name="LimOvrUnit" type="xsd:float" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/><xsd:attribute name="ServUnit" type="xsd:float" use="required"/><xsd:attribute name="TokuchiSubj" type="ce02" use="required"/><xsd:attribute name="TotalUnit" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="Communication"><xsd:complexType/></xsd:element><xsd:element name="DailyAct"><xsd:complexType/></xsd:element><xsd:element name="DailyLife">

64<xsd:complexType/></xsd:element><xsd:element name="DailyService̲Plan"><xsd:complexType><xsd:attribute name="Count" type="xsd:float" use="required"/><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="DayW" type="ce03" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="TimeScale.eddt" type="xsd:time" use="optional"/><xsd:attribute name="TimeScale.stdt" type="xsd:time" use="optional"/></xsd:complexType></xsd:element><xsd:element name="DailyService̲Result"><xsd:complexType><xsd:attribute name="Count" type="xsd:float" use="required"/><xsd:attribute name="Date" type="xsd:date" use="required"/><xsd:attribute name="DayW" type="ce03" use="required"/><xsd:attribute name="refPlan" type="xsd:IDREFS" use="optional"/><xsd:attribute name="TimeScale.eddt" type="xsd:time" use="optional"/><xsd:attribute name="TimeScale.stdt" type="xsd:time" use="optional"/></xsd:complexType></xsd:element><xsd:element name="DailyWork"><xsd:complexType/></xsd:element><xsd:element name="Depression"><xsd:complexType/></xsd:element><xsd:element name="DivPayMaxMng"><xsd:complexType><xsd:sequence><xsd:element ref="ClsPayMaxMng" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="AllOwnPay" type="xsd:float" use="required"/><xsd:attribute name="ClsLimFixU" type="xsd:float" use="required"/><xsd:attribute name="ClsLimOvrU" type="xsd:float" use="required"/>65

<xsd:attribute name="DivLimFixU" type="xsd:float" use="required"/><xsd:attribute name="DivLimOvrU" type="xsd:float" use="required"/><xsd:attribute name="InsOwnPay" type="xsd:float" use="required"/><xsd:attribute name="InsPay" type="xsd:float" use="required"/><xsd:attribute name="InsTotal" type="xsd:float" use="required"/><xsd:attribute name="ServUnit" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="Exercise"><xsd:complexType/></xsd:element><xsd:element name="Forget"><xsd:complexType/></xsd:element><xsd:element name="GetInf"><xsd:complexType/></xsd:element><xsd:element name="GrantService"><xsd:complexType><xsd:attribute name="refPS̲Service" type="xsd:IDREF" use="required"/></xsd:complexType></xsd:element><xsd:element name="HcareD"><xsd:complexType><xsd:sequence><xsd:element ref="DailyService̲Plan" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="DailyService̲Result" minOccurs="0" maxOccurs="unbounded"/><xsd:choice><xsd:element ref="NoGrantService" minOccurs="0"/><xsd:element ref="GrantService" minOccurs="0"/></xsd:choice></xsd:sequence><xsd:attribute name="DisUnit" type="xsd:float" use="required"/><xsd:attribute name="InsrSubj" type="ce02" use="required"/><xsd:attribute name="Percent" type="xsd:float" use="required"/><xsd:attribute name="PlanTotal" type="xsd:float" use="required"/>66

<xsd:attribute name="refCareServComp" type="xsd:IDREF" use="optional"/><xsd:attribute name="ResultTotal" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="HealthManagement"><xsd:complexType/></xsd:element><xsd:element name="Help̲Target"><xsd:complexType/></xsd:element><xsd:element name="HomeCareHist"><xsd:complexType><xsd:attribute name="CorpName" type="xsd:string" use="required"/><xsd:attribute name="RepDate" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeHelper"><xsd:complexType><xsd:sequence><xsd:element ref="Name"/></xsd:sequence><xsd:attribute name="id" type="xsd:ID" use="required"/></xsd:complexType></xsd:element><xsd:element name="HomeHelperOffice"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/><xsd:element ref="HomeHelper" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/><xsd:attribute name="PhoneNo" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="InfSys">67

<xsd:complexType/></xsd:element><xsd:element name="Insr"><xsd:complexType><xsd:sequence><xsd:element ref="Assr" minOccurs="0"/><xsd:element ref="Assd"/><xsd:element ref="CareNec"/></xsd:sequence><xsd:attribute name="Authorized" type="ce02" use="required"/><xsd:attribute name="IssueDate" type="xsd:date" use="optional"/><xsd:attribute name="LimitDate" type="xsd:date" use="optional"/><xsd:attribute name="Num" type="xsd:string" use="optional"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/></xsd:complexType></xsd:element><xsd:element name="LackExercise"><xsd:complexType/></xsd:element><xsd:element name="LifeTarget"><xsd:complexType/></xsd:element><xsd:element name="MsgPack"><xsd:complexType><xsd:sequence><xsd:element ref="CarePlan" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType></xsd:element><xsd:element name="Name"><xsd:complexType><xsd:attribute name="fmn" type="xsd:string" use="optional"/><xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:complexType></xsd:element><xsd:element name="NameKana">

68<xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attribute name="fmn" type="xsd:string" use="optional"/><xsd:attribute name="gvn" type="xsd:string" use="optional"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element><xsd:element name="NoGrantService"><xsd:complexType><xsd:attribute name="ServCls" type="xsd:string" use="required"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Nutrition"><xsd:complexType/></xsd:element><xsd:element name="Oral"><xsd:complexType/></xsd:element><xsd:element name="OwnPayMax"><xsd:complexType><xsd:attribute name="Detail" type="xsd:string" use="required"/><xsd:attribute name="PayMax" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="PayLimit"><xsd:complexType><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/><xsd:attribute name="LimitCont" type="xsd:string" use="required"/><xsd:attribute name="PayPercent" type="xsd:float" use="optional"/><xsd:attribute name="ServCont" type="xsd:string" use="required"/></xsd:complexType></xsd:element>69

<xsd:element name="PayMax"><xsd:complexType><xsd:sequence><xsd:element ref="ClsPayMax" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Base" type="xsd:float" use="required"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="required"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="required"/></xsd:complexType></xsd:element><xsd:element name="Policy"/><xsd:element name="PresentPlan"><xsd:complexType/></xsd:element><xsd:element name="PrevHomeHelperOffice"><xsd:complexType><xsd:sequence><xsd:element ref="Address"/><xsd:element ref="HomeHelper" maxOccurs="unbounded"/></xsd:sequence><xsd:attribute name="Name" type="xsd:string" use="required"/><xsd:attribute name="Num" type="xsd:string" use="required"/><xsd:attribute name="PhoneNo" type="xsd:string" use="required"/></xsd:complexType></xsd:element><xsd:element name="Prob"><xsd:complexType/></xsd:element><xsd:element name="ProbMeasure"><xsd:complexType/></xsd:element><xsd:element name="PS̲Service"><xsd:complexType><xsd:attribute name="ClsPayMaxSubj" type="ce02" use="required"/><xsd:attribute name="id" type="xsd:ID" use="required"/><xsd:attribute name="ServCls" type="xsd:string" use="required"/>70

<xsd:attribute name="ServCont" type="xsd:string" use="required"/><xsd:attribute name="UnitNum" type="xsd:float" use="required"/><xsd:attribute name="UnitPrice" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="PubPay"><xsd:complexType><xsd:attribute name="BeneficiaryNo" type="xsd:string" use="optional"/><xsd:attribute name="Cls" type="xsd:string" use="required"/><xsd:attribute name="IssueDate" type="xsd:date" use="optional"/><xsd:attribute name="LifeTime.eddt" type="xsd:date" use="optional"/><xsd:attribute name="LifeTime.stdt" type="xsd:date" use="optional"/><xsd:attribute name="PayName" type="xsd:string" use="optional"/><xsd:attribute name="PayNo" type="xsd:string" use="optional"/><xsd:attribute name="Percent" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="SStyDays"><xsd:complexType><xsd:attribute name="LstMonthUseDays" type="xsd:float" use="required"/><xsd:attribute name="SumUseDays" type="xsd:float" use="required"/><xsd:attribute name="ThisMonthPlanUseDays" type="xsd:float" use="required"/></xsd:complexType></xsd:element><xsd:element name="TotalPlan"><xsd:complexType/></xsd:element><xsd:element name="Week"><xsd:complexType/></xsd:element><xsd:element name="Withdraw"><xsd:complexType/></xsd:element><xsd:simpleType name="ce01"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="F"/>71

<xsd:enumeration value="M"/><xsd:enumeration value="O"/><xsd:enumeration value="U"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce02"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="Y"/><xsd:enumeration value="N"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce03"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="SAT"/><xsd:enumeration value="SUN"/><xsd:enumeration value="MON"/><xsd:enumeration value="TUE"/><xsd:enumeration value="WED"/><xsd:enumeration value="THU"/><xsd:enumeration value="FRI"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce05"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="N"/><xsd:enumeration value="D"/><xsd:enumeration value="U"/><xsd:enumeration value="OK"/><xsd:enumeration value="NG"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce06"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="51"/><xsd:enumeration value="52"/><xsd:enumeration value="53"/>72

</xsd:restriction></xsd:simpleType><xsd:simpleType name="ce07"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="21"/><xsd:enumeration value="22"/><xsd:enumeration value="23"/><xsd:enumeration value="24"/><xsd:enumeration value="25"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce10"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="01"/><xsd:enumeration value="02"/><xsd:enumeration value="03"/><xsd:enumeration value="04"/><xsd:enumeration value="05"/><xsd:enumeration value="06"/><xsd:enumeration value="07"/><xsd:enumeration value="08"/><xsd:enumeration value="09"/><xsd:enumeration value="10"/><xsd:enumeration value="11"/><xsd:enumeration value="12"/><xsd:enumeration value="13"/><xsd:enumeration value="99"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce11"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="11"/><xsd:enumeration value="12"/>73

<xsd:enumeration value="21"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce12"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/><xsd:enumeration value="2"/><xsd:enumeration value="3"/></xsd:restriction></xsd:simpleType><xsd:simpleType name="ce13"><xsd:restriction base="xsd:NMTOKEN"><xsd:enumeration value="1"/><xsd:enumeration value="2"/></xsd:restriction></xsd:simpleType></xsd:schema>

―以上−

74

このページは空白です。

75

別添資料４−２

介護標準メッセージ仕様【XML による介護事業者間データ交換仕様】※

データ項目構造のみを抜粋

平成 19 年 3 月

改訂

保健医療福祉情報システム工業会

1

【目次】

１．メッセージ構造 ····················································· 3
１．１．介護保険証情報················································· 3

１．１．居宅サービス計画書情報
１．１．サービス提供票情報········································· 6············································· 12

１．１．予防サービス計画書情報········································· 20

１．１．予防サービス提供票情報········································· 28

２．関連情報 ··························································· 36
２．１ 項目辞書 ······················································· 36
２．２ データ形式一覧
２．３ コード体系················································· 43····················································· 44＜参考資料＞(介護帳票)··················································· 46①居宅サービス計画書(1)②居宅サービス計画書(2)③週間計画表④サービス提供票⑤サービス提供票(別表)⑥介護予防サービス・支援計画表2

１．メッセージ構造
１．１．介護保険証情報のタグセット構造（データ項目構造）
maxOccurs

minOccurs

項番

1
2

L1

L2

L3

L4

L5

L6

L7

属性

サンプル

MsgPack
1

unbounded

GetInfxxxxxx4

Status

N

5

Note
1

型

InfSys

ID

ST

ステータス

CE

コメント

ST

UserID

ユーザ IDST

8

Passwd

パスワード

ST

認定済

CE

1

1

Insr

被保険者認定10

Authorized

11

LimitDate

2002-09-30

有効期限

DT

12

Num

0123456789

番号

ST

13

IssueDate

2001-04-01

14

PayPercent

90

Num

123456

Name

介護市

15

0

1

1

Assd
Birthday

1932-10-02

20

Sex

M

21

PhoneNo
0

1

DT
NM

番号

ST

名称

ST

生年月日

DT

被保険者

19

22

交付年月日
給付率

2

保険者

17
1

Y

Assr

16

18

5

保険証情報提供システム情報

7

9

表

取得情報
ID

0

属性名

通信用梱包

3

6

クラス名

神奈川県介護市
介護区中田 890

Address

3

性別

CE

電話番号

TN

住所

AD

1

23

zip

24

state

神奈川県

(ST)

25

city

介護市介護区

(ST)

26
27

strt
1

1

Name

212-8567

中田 890

28

fmn

29

gvn

太郎

0

1

(ST)

介護太郎
介護

30

(ST)

NameKana

氏名

PN
(ST)
(ST)

カイゴタロウ

氏名フリガナ

PN

31

fmn

カイゴ

(ST)

32

gvn

タロウ

(ST)

34

CorpName

電電ケアライフ(ケアマネージャー①)

35

RepDate2001-02-20

33

36

0

0

unbounded

HomeCareHist

unbounded

居宅介護支援事業者履歴

CareFaclHist

事業所名称

ST

届出年月日

DT

介護保険施設等履歴37

FaclKind

種類

CE

38

FaclName

名称

ST

39

InDate入所入院年月日DT40

OutDate退所退院年月日DT

要介護状態区分

CE

41

1

1

CareNec

要介護認定

42

Rank

22

43

CertDate

2001-04-01

認定年月日

DT

44

LifeTime.stdt

2001-04-01

有効期間

DR(TS)

45

LifeTime.eddt

2001-09-30

有効期間

DR(TS)

46

JudgeNote

特になし

認定審査会意見ST

LimitCont

制限内容

ST

49

ServCont

サービス内容50

LifeTime.stdt

47
48

0

unbounded

6

PayLimit

7

給付制限

4

期間

CE
DR(TS)

9

51

LifeTime.eddt

52
53

PayPercent
0

1

PayMax

期間

DR(TS)

給付率

NM

居宅サービス限度額

54

Base

19480

基準額

NM

55

LifeTime.stdt

2001-04-01

期間

DR(TS)

56

LifeTime.eddt

2002-09-30

期間

DR(TS)

57

0

unbounded

ClsPayMax

種類支給限度額

58

ServCls11

サービス種類CE59

ClsBasisPay

100

基準額

NM

5

8

１．２．居宅サービス計画書情報のタグセット構造（データ項目構造）
minOccurs

maxOccurs

項番1

unbounded

1
2

L1

L2

L3

L4

L5

L6

L7

属性

MsgPack

クラス名

4

Status5xxxxxx

ID

ST

N

ステータス

CE

コメント

ST

Note
1

型

CareServ
Status

11

ステータス

CE

8

UserReq

本人は「長女の世話にはなるが、あまり(長女に)負担をかけたくない」と言う。サービス
利用については比較的前向きである(入浴できるのならデイサービスを利 用してもよい)。
長女 (主介護者 )は自分が介護するつもりである。ただし、朝 ・夕食の 準備 はできるが、商売の都合で昼食の準備ができない。
また、 閉 じこもり が ちにな ることを心 配 して、、デイサービスの利用を希望している。

利用者意向

ST

9

TotalPlan

統 合的 な援 助の
方針

ST

コメント

ST

算定理由

CWE

算定理由

(ST)

10

Note

11

refHomeHelper
11

CalcReason

1

1

Insr

hh001

cd

3
被保険者認定6

11

IDREF 型：HomeHelper を指す

特になし

13
14

5

居宅介護サービス

7

12

表

連携情報
ID

1

属性名

通信用梱包
CarePlan

3

6

サンプル

12

15

AuthorizedY

16

LimitDate

17

Num

18
19
20

0

1

認定済

CE

2002-09-30

有効期限

DT

0123456789

番号ST

IssueDate

2001-04-01

交付年月日

DT

PayPercent

90

給付率

NM

Assr

保険者

21

Num

123456

番号

ST

22

Name

介護市

名称

ST

Birthday

1932-10-02

生年月日

DT

23

1

1

Assd

被保険者

24
25

Sex

26

PhoneNo

27

0

1

M

神奈川県介護市介護区中田 890

Address

性別

CE

電話番号

TN

住所

zip

212-8567

(ST)

29

state

神奈川県

(ST)

30

city

介護市介護区(ST)

strt

中田 890

31
1

1

Name
fmn

介護

34

gvn

太郎

35

0

1

(ST)

介護太郎

33

NameKana

氏名

PN
(ST)
(ST)

カイゴタロウ

氏名フリガナ

PN

36

fmn

カイゴ

(ST)

37

gvn

タロウ

(ST)

38

0

unbounded

HomeCareHist

居宅介護支援事業者履歴

39
40
41

0

unbounded

1

AD

28

32

2

CorpName

電電ケアライフ(ケアマネージャー①)

RepDate2001-02-20

CareFaclHist

事業所名称

ST

届出年月日

DT

種類

CE

介護保険施設等履歴42

FaclKind

7

6

43

FaclName

名称

ST

44

InDate入所入院年月日DT

45

OutDate退所退院年月日DT22

要介護状態区分

CE
DT

46

1

1

CareNec

要介護認定

47

Rank

48

CertDate

2001-04-01

認定年月日

49

LifeTime.stdt

2001-04-01

有効期間

DR(TS)

50

LifeTime.eddt

2001-09-30

有効期間

DR(TS)

JudgeNote

特になし

51
52

0

unbounded

PayLimit

認定審査会意見

ST

給付制限

53

LimitCont

制限内容

ST

54

ServCont

サービス内容CE

55

LifeTime.stdt

期間DR(TS)

56

LifeTime.eddt

期間

DR(TS)

給付率

NM

57
58

PayPercent
0

1

PayMax
Base

19480

基準額

NM

60

LifeTime.stdt

2001-04-01

期間

DR(TS)

LifeTime.eddt

2002-09-30

期間

DR(TS)

61
0

unbounded

ClsPayMax

63
64
65

1

1

ChgHist_First

01

ChgHist_Recent

0

unbounded

ServCls11

ClsBasisPay

100

Date

サービス種類

CE

基準額

NM

2000-05-06

日付

DT

日付

DT

内容

ST

履歴_最新

68
69

種類支給限度額

履歴_初回

66
67

9

居宅サービス限度額

59

62

7

Date
DailyAct

2000-05-06
日常活動

70

Detail8871TimeBand.stdt

72
73

TimeBand.eddt
1

unbounded

Help_Target

時間帯

DR(TS)

時間帯

DR(TS)

援助目標

74

LongT

共同トイレの一部を様式にする

長期目標

ST

75

LTPeriod

1 ヶ月

長期目標の期間

ST

76

ShortT

排便、夜間の排尿を安全に行う

短期目標

ST

77

STPeriod

2 週間

短期目標の期間

ST

78

id

ht001

refProb

p001

課題

ST

79
80

1

unbounded

Prob
Detail82

id1

unbounded

IDREFS 型：Prob を指す
生活全般の課題

81

83

ID 型：HCareD から指される

右半身麻痺のため和 式トイレが 使えない(ので困る)
p001

HcareD

ID 型：Help_Target から指される
居宅介護サービス内容

84

Outlineポータブルトイレ給付(据え置き便座によりトイレを洋式化 する)

サービス内容概要

ST

85

InsrSubj

Y

保険給付対象CEST

86ClassOL

日常生活用具給付等事業

サ ー ビ ス種 類 概
要

87

Freq

1回

頻度

ST

88

Period

直ちに

期間

ST

89

refHelp_Target

ht001

IDREFS 型：Help_Target を指す

90

refCareServComp csc001

IDREF 型：CareServComp を指す

9

2

91

0

unbounded

DailyWork

日課

92

Timeband.stdt

時間帯

DR(TS)

93

Timeband.eddt

時間帯

DR(TS)

Day

曜日

CE

Timeband.stdt

時間帯

DR(TS)

Timeband.eddt

時間帯

DR(TS)

94

0

unbounded

Week

週間

選択

95
96
97
98

0

unbounded0

1

AnyTime

随時

99
100

Add
NoGrantService

102
103

ServCls

選択

101

0

1

1

unbounded

ServCont
GrantService

ST

サービス種類ST

サービス内容ST

給付対象サービス

104
105

実施補足情報給付対象外サービス

refPS_Service

ps001

HomeHelperOff ice

IDREF 型：PS_Service を指す
居宅介護支援事業者

106

Num

0000000043

事業所番号

ST

107

Name

介護市居宅介護支援センタ

名称

ST

108
109

PhoneNo1

1(1234)1234-1234

Address

電話番号

TN

所在地

AD

110

zip

(ST)

111

state

(ST)

112

city

(ST)

113
114

strt
1

unbounded11

居宅介護支援担当者

115
116

(ST)

HomeHelper
id
Name

hh001
介護花子

ID 型：CareServ から指される
氏名

PN

117

fmn

(ST)

118

gvn

(ST)

10

3

119

0

unbounded

CareServComp

居宅介護サービス事業者

120

Kind

01

事業所種別

CE

121

Num

1234567890

事業所番号

ST

122

Name

訪問介護センタ

名称

ST

123

PhoneNo

電話番号

TN

124

SatelliteInf

サテライト区分

ST

125

id

所在地

AD

126

1

1

Address

csc001

ID 型：HcareD から指される

広島県広島市中区白島北町

127

zip

730-0001

(ST)

128

state

広島県

(ST)

129

city

広島市中区

(ST)

130

strt

白島北町

(ST)

131

0

unbounded

PS_Service

10

サービス

132

ServCont

3421

サービス内容CE133

UnitNum

1022

単位数

NM

134

ClsPayMaxSubj

Y

限度額適用対象

CE

2

135

ServCls15

サービス種類CE

8

136

UnitPrice

10.18

単価

MO

137

id

ps001

138

11

ID 型：GrantService から指される

9

１．３．サービス提供票情報のタグセット構造（データ項目構造）
minOccurs

maxOccurs

項番1

unbounded

1
2

L1

L2

L3

L4

L5

L6

L7

属性

MsgPack

クラス名

ID
Status5xxxxxx

ID

ST

N

ステータス

CE

コメント

ST

Note
1

型

CareServ
Date

2001-09-01

対象年月

DT

8

AssrConf

123456

保険者確認

ST

9

MDate

2001-09-01

作成年月日

DT

10

RepDate2001-04-01

届出年月日

DT

11

Note

これは提供票サンプル用の XML イ
ンスタンスです。

コメント

ST

12

refHomeHelper
1

1

hh001

Insr

IDREF 型：HomeHelper を指す
被保険者認定14

Authorized

Y

認定済

CE

15

LimitDate

2002-09-30

有効期限

DT

16

Num

0123456789

番号

ST

17

IssueDate

2001-04-01

交付年月日

DT

PayPercent

90

給付率

NM

18
19

0

1

Assr

保険者

20

Num

123456

番号

ST

21

Name

介護市

名称

ST

22

1

1

5

居宅介護サービス

7

13

表

連携情報

4

1

属性名

通信用梱包
CarePlan

3

6

サンプル

Assd

被保険者

12

2

23

Birthday

24

Sex

25

PhoneNo2601

1932-10-02

生年月日

M

性別

CE

電話番号

TN

神奈川県介護市介護区中田 890

Address

住所

DT

AD

27

zip

212-8567

(ST)

28

state

神奈川県

(ST)

29

city

介護市介護区

(ST)

30

strt

中田 890

(ST)

31

1

1

Name

介護太郎

32
33
34

0

1

fmn

介護

gvn

太郎

NameKana

氏名

PN
(ST)
(ST)

カイゴタロウ

氏名フリガナ

PN

35

fmn

カイゴ

(ST)

36

gvn

タロウ

(ST)

37

0

unbounded

HomeCareHist

居宅介護支援事業者履歴

38
39
40

0

unbounded

CorpName

電電ケアライフ(ケアマネージャー①)

RepDate2001-02-20

CareFaclHist

事業所名称

ST

届出年月日

DT

介護保険施設等履歴41

FaclKind

種類

CE

42

FaclName

名称

ST

43

InDate入所入院年月日DT

44

OutDate退所退院年月日DT22

要介護状態区分

CE

45

1

1

1

CareNec

6

要介護認定

46

Rank

47

CertDate

2001-04-01

認定年月日

DT

48

LifeTime.stdt

2001-04-01

有効期間

DR(TS)

49

LifeTime.eddt

2001-09-30

有効期間

DR(TS)

50

JudgeNote

特になし

認定審査会意見

13

ST

7

51

0

unbounded

PayLimit

給付制限

52

LimitCont

制限内容

ST

53

ServCont

サービス内容CE

54

LifeTime.stdt

期間DR(TS)

55

LifeTime.eddt

期間

DR(TS)

56

PayPercent

給付率

NM

19480

基準額

NM

57

0

1

PayMax

居宅サービス限度額

58

Base

59

LifeTime.stdt

2001-04-01

期間

DR(TS)

60

LifeTime.eddt

2002-09-30

期間

DR(TS)

61

0

unbounded

ClsPayMax

62
63
64

0

1

9

種類支給限度額
ServCls11

ClsBasisPay

100

DivPayMaxMng

サービス種類

CE

基準額

NM

8

区分支給限度管理

65

ServUnit

22807

単位数

NM

66

ClsLimOvrU

22207

種類基準超単位数

NM

67

ClsLimFixU

600

種類基準内単位数

NM

68

DivLimOvrU

0

区分基準超単位数

NM

69

DivLimFixU

600

区分基準内単位数

NM

70

InsTotal

6330

保険対象総額MO

71

InsPay

5696

保険給付額

MO

72

InsOwnPay634

保険対象利用者負担MO

73

AllOwnPay

249686

全額負担利用者負担

MO

TokuchiSubj

Y

特地加算対象CE

2

76

ServCls15

サービス種類CE

877

TotalUnit

3400

合計単位数

NM

78

LimOvrUnit

200

限度超単位数NM

74

0

unbounded

ClsPayMaxMng

種類別支給限度管理

75

14

79

ClsPayMaxSubj

Y

限度額適用対象

CE

80

ServUnit

3400

単位数

NM

81

ClsLimOvrU

3200

種類基準超単位数

NM

82

ClsLimFixU

200

種類基準内単位数

NM

83

DivLimOvrU

0

区分基準超単位数

NM

84

DivLimFixU

200

区分基準内単位数

NM

85

InsTotal2036

保険対象総額MO

86

InsPay

1832

保険給付額

MO

87

InsOwnPay

204

保険対象利用者負担MO

88

AllOwnPay

32575

全額負担利用者負担MO

90

ServUnit

19407

単位数

NM

91

ClsLimOvrU

21642

種類基準超単位数

NM

92

ClsLimFixU

415

種類基準内単位数

NM

93

DivLimOvrU

0

区分基準超単位数

NM

94

DivLimFixU

415

区分基準内単位数

NM

95

InsTotal4294

保険対象総額MO

96

InsPay

3864

保険給付額

MO

97

InsOwnPay

430

保険対象利用者負担MO

98

AllOwnPay27111

全額負担利用者負担

MO

前月までの利用日数NM

当月計画利用日数NM

累積利用日数

NM

89

99

0

0

1

1

AnotherDivPayMaxMng

他区分支給限度管理

SStyDays

短期入所利用日数100

LstMonthUseDays

101

ThisMonthPlanUseDays 3

102

SumUseDays

15

10

13

2

103

0

unbounded

PubPay

公費給付

104

Cls

サービス種類CE

105

Percent

給付率

NM

106

IssueDate

交付年月日

DT

107

PayNo

公費負担者番号ST

PayName

公費負担者名称

ST

108

選択

109
110
111
112

BeneficiaryNo

受給者番号

ST

LifeTime.stdt

有効開始日

DT

有効終了日

DT

LifeTime.eddt
0unbounded

OwnPayMax

自己負担上限113

Detail

内容

ST

114

PayMax

金額

MO

日付

DT

要介護状態区分

CE

115

1

1

CareRankHist_First

状態履歴_初回

116
117
118

0

1

8

Date

2001-04-01

Rank

22

CareRankHist_Recent7

状態履歴_最新

119

Date

日付

DT

120

Rank

要介護状態区分

CE

7

2

121

1

unbounded

HcareD

居宅介護サービス内容

122

InsrSubj

Y

保険対象

CE

123

PlanTotal

4

予定合計回数NM

124

ResultTotal

4

実績合計回数NM

125

DisUnit715

割引後単位数NM

126

Percent

割引率

NM

127

refCareServComp

csc001TimeScale.stdt

11:00:00.00

1280unbounded

DailyService_Plan

IDREF 型：CareServComp を指す
日毎サービス提供_予定

129

16

提供時間帯

DR(TS)

130

TimeScale.eddt

17:00:00.00

提供時間帯

131

Date

2001-09-04

日付

DT

132

DayW

TUE

曜日

CE

133

Count

1

回数

NM

134

id

135

0

unbounded

dsp001

DailyService_Result

DR(TS)

3

ID 型：DailyService_Result から指される
日毎サービス提供_実績

136

TimeScale.stdt

11:00:00.00

提供時間帯

DR(TS)137

TimeScale.eddt

17:00:00.00

提供時間帯

DR(TS)

138

Date

2001-09-04

日付

DT

139

DayW

TUE

曜日

CE

140

Count

1

回数

NM

141

refPlandsp001

17

IDREFS 型：DailyService_Plan を指す

3

142

0

1

NoGrantService

選択

143
144
145

給付対象外サービス

01

サービス種類ST

サービス内容ST

GrantService

給付対象サービス

146
147

ServCls
ServCont

refPS_Service
1

unbounded

ps001

HomeHelperOffice

IDREF 型：PS_Service を指す
居宅介護支援事業者

148

Num

0000000043

事業所番号

ST

149

Name

介護市居宅介護支援センタ

名称ST(1234)1234-1234

電話番号

TN

所在地

AD

150
151

PhoneNo1

1

Address

152

zip

(ST)

153

state

(ST)

154

city

(ST)

155

strt

(ST)

156

1

unbounded

HomeHelper

居宅介護支援担当者

157
158

id
1

1

Name

ID 型：CareServ から指される

介護花子

159

氏名

fmn

160
161

hh001

gvn
0

unbounded

PN
(ST)
(ST)

CareServComp

居宅介護サービス事業者

162

Kind

01

事業所種別

CE

163

Num

1234567890

事業所番号

ST

164

Name

訪問介護センタ

名称

ST

165

PhoneNo

電話番号

TN

166

SatelliteInf

サテライト区分

ST

所在地

AD

167
168

id
1

1

Address

csc001
広島県広島市中区白島北町

18

ID 型：HcareD から指される

10

169

zip

730-0001

(ST)

170

state

広島県

(ST)

171

city

広島市中区

(ST)

strt

白島北町

172
173

0

unbounded

PS_Service

(ST)
サービス

174

ServCont

3421

サービス内容CE

175

UnitNum

1022

単位数

NM

176

ClsPayMaxSubj

Y

限度額適用対象

CE

2

177

ServCls15

サービス種類CE

8

178

UnitPrice

10.18

単価

MO

179

id

ps001

180

19

ID 型：GrantService から指される

9

１．４．予防サービス計画書情報のタグセット構造（データ項目構造）
minOccurs

maxOccurs

項番1

unbounded

1
2

L1

L2

L3

L4

L5

L6

L7

属性

MsgPack

ID
Status

5
1

ID

ST

N

ステータス

CE

コメント

ST

11

ステータス

CE

111111111

No（地域包括支援センター
で付す任意の番号）

ST

コメント

ST

CareServ
Status

8

No

9

Note

10

refHomeHelper
1

hh001

Insr
Y

認定済

CE

13

LimitDate

2002-09-30

有効期限

DT

14

Num

0123456789

番号

ST

15

IssueDate

2001-04-01

交付年月日

DT

PayPercent

90

給付率

NM

16
1

Assr

保険者

18

Num

123456

番号

ST

19

Name

介護市

名称

ST

21

age

74

年齢

MO

22

Birthday

1932-10-02

生年月日

DT

20

1

1

11

被保険者認定Authorized

0

5

IDREF 型：HomeHelper を指す

12

17

表

介護予防サービス

7

1

型

xxxxxx

Note
1

属性名

連携情報

4

11

クラス名

通信用梱包
CarePlan

3

6

サンプル

Assd

被保険者

20

2

23

Sex

24
25

M

PhoneNo01

Address

神奈川県介護市

性別

CE

電話番号

TN

住所

AD

26

zip

212-8567

(ST)

27

state

神奈川県

(ST)

28

city

介護市介護区

(ST)

29

strt

890

30

1

1

Name

(ST)

介護太郎

氏名

PN

31

fmn

介護

(ST)

32

gvn

太郎

(ST)

33

0

1

NameKana

34
35
36

0

unbounded

カイゴタロウ
fmn

カイゴ

gvn

タロウ

氏名フリガナ

PN
(ST)
(ST)

介護予防支援
事業者履歴

HomeCareHist

37

CorpName

介護市地域包括支援センター

事業所名称

ST

38

RepDate2006-08-20

届出年月日

DT

CE

39

0

unbounded

CareFaclHist

介護保険施設等履歴40

FaclKind

種類

41

FaclName

名称

ST

42

InDate入所入院年月日DT

退所退院年月日DT

43
44

OutDate
1

1

CareNec
Rank

１２

要介護状態区分

CE

46

CertDate

2006-09-01

認定年月日

DT

47

LifeTime.stdt

2006-09-01

有効期間

DR(TS)

48

LifeTime.eddt

2007-03-30

有効期間

DR(TS)

制限内容

ST

0

unbounded

6

要介護認定

45

49

1

PayLimit

給付制限

50

LimitCont

21

7

51

ServCont

サービス内容CE

52

LifeTime.stdt

期間DR(TS)

53

LifeTime.eddt

期間

DR(TS)

給付率

NM

54
55

PayPercent
0

1

PayMax

サービス限度額

56

Base

57

LifeTime.stdt

58

LifeTime.eddt

590unbounded

61
1

1

ChgHist_First

01

ChgHist_RecentDR(TS)

2007-03-30

期間

DR(TS)

1

unbounded1

unbounded

種類支給限度額34

ClsBasisPay100

サービス種類

CE

基準額

NM

日付

DT

日付

DT

健康状態の留意点

ST

2006-08-25

Date
Assesment

2006-08-25
アセスメント内容

Attention
Exercise

運動・移動

69

Condition

現在の状況

ST

70

UserReq

本人・家族の意欲・意向

ST

71

Check

領域における課題の有無

CE

領域における課題

ST

72
73

Prob
1

unbounded

DailyLife
Condition

現在の状況

ST

75

UserReq

本人・家族の意欲・意向

ST

76

Check

領域における課題の有無

CE

77

Prob

領域における課題

ST1

unbounded

13

日常生活

74

78

8

履歴_最新

67
68

期間

ServCls

Date

65
66

NM

2006-09-01

履歴_初回

63
64

基準額

ClsPayMax

60

62

9

Communication

コミュニケーション

22

13

79

Condition

現在の状況

ST

80

UserReq

本人・家族の意欲・意向

ST

81

Check

領域における課題の有無

CE

領域における課題

ST

82
83

Prob
1

unbounded

HealthManagement

健康管理

84

Condition

現在の状況

ST

85

UserReq

本人・家族の意欲・意向

ST

86

Check

領域における課題の有無

CE

領域における課題

ST

総合的課題

ST

87
88

Prob
1

unbounded

ProbMeasure

課題と対策

89

TotalProb

90

TargetMeasure

課題に対する目標と具体策の提案ST

91

UserReq

本人・家族の具体策についての意向

ST

目標：1 日

ST

目標：年

ST

内容

ST

内容

ST

内容

ST

92

id

93

1

unbounded

94

1

1

ID 型：Target から指される
目標・方針

LifeTarget

目標とする生活
DayTarget

96

YearTarget
1

1

TotalPlan0

unbounded

PresentPlan

101

1

unbounded102

1

unbounded

総合的な方針

98
99

pm001

Policy95

97

13

Detail
妥当な支援に向けた方針

100

DetailHcareD

予防支援計画内容
Target目標

103

Detail

104

id

23

t001

ID 型：Point から指される

13

105
106

refProbMeasure1

unbounded

pm001

Point

支援のポイント

107

Detail

内容

108

id

p001

109

refTarget

t001

110

IDREFS 型：ProbMeasure を指す

1

unbounded

SupportPlan

ST

ID 型：SupportPlan から指される
IDREFS 型：Target を指す
支援内容

111

OtherSupport

112

Outline

一緒に買い物に行く

家族の支援等のインフォーマルサービス

ST

身 体に負担になるような家事 はヘルパーに依頼

介護保険サービス
又は地域支援事業

ST

113

id

sp001

ID 型：Servkind から指される

114

refPoint

p001

IDREFS 型：Point を指す

ClassOL

介護予防訪問介護介護予防サービス種別

ST

117

Period

3 ヶ月
平成 18 年 9 月 1 日〜平成 18 年
11 月 30 日

期間

ST

118

Name

○×介護予防サービス事業者

事業所名称

ST

115

1

unbounded

ServKind

サービス種類

116

119

refSupportPlan

120

refCareServComp csc001

24

sp001

IDREFS 型：SupportPlan を指す
IDREFS 型：CareServComp を指す

121

0

unbounded

DailyWork

日課122

Timeband.stdt

時間帯

DR(TS)

123

Timeband.eddt

時間帯

DR(TS)

Day

曜日

CE

Timeband.stdt

時間帯

DR(TS)

Timeband.eddt

時間帯

DR(TS)

124

0

unbounded

Week

週間

選択

125
126
127
128

0

unbounded0

1

AnyTime

随時

129
130

Add
NoGrantService

実施補足情報ST

給付対象外サービス

131

ServCls

サービス種類ST

132

ServCont

サービス内容

ST

0

1

選択

133
134
135

1

1

GrantService

給付対象サービス
refPS_Service

Agreement
Date

1

1

138

1

1

IDREF 型：PS_Service を指す
計画に同意した日付

136
137

ps001

CheckList

2006-08-2５

日付

DT

チェックリストの該当個数
LackExercise

運動不足

139

TotalQuestion

質問総数

MO

140

Question

該当質問数

MO

141

1

1

Nutrition

栄養改善

142

TotalQuestion

質問総数

MO

143

Question

該当質問数

MO

質問総数

MO

該当質問数

MO

144

1

1

Oral

口腔内ケア

145

TotalQuestion

146
147

Question1

1

Withdraw

閉じこもり予防

25

3

148

TotalQuestion

149
150

Question11Forget

質問総数

MO

該当質問数

MO

物忘れ防止

151

TotalQuestion

質問総数

MO

152

Question

該当質問数

MO

154

TotalQuestion

質問総数

MO

155

Question

該当質問数

MO

153

156

1

0

1

Depression

unbounded

DailyAct

日常活動

157

Detail

内容

ST

158

TimeBand.stdt

時間帯

DR(TS)

時間帯

DR(TS)

159
160

TimeBand.eddt
1

unbounded

PrevHomeHelperOff ice

地域包括支援センター

161

Num

0000000043

事業所番号

ST

162

Name

介護市地域包括支援センター

名称

ST

電話番号

TN

計画に対する意見

ST

163

PhoneNo

164

Comment165

1

1Address(1234)1234-1234

住所情報

所在地

AD

166

zip

(ST)

167

state

(ST)

168

city

(ST)

169
170

strt
1

unbounded

居宅介護支援担当者

171
172

id
1

1

Name

hh002

ID 型：CareServ から指される

介護花美

173

氏名

fmn

174
175

(ST)

HomeHelper

gvn
1

unbounded

HomeHelperOff ice(ST)
居宅介護支援事業者

26

PN
(ST)

176

Num

0000000043

事業所番号

177

Name

介護市介護予防支援事業者

名称

ST

178

PhoneNo(1234)1234-1234

電話番号

TN

住所情報

所在地

179

1

1

Address

ST

AD

180

zip

(ST)

181

state

(ST)

182

city

(ST)

183

strt

(ST)

184

1

unbounded

185

0

unbounded

HomeHelper

介護予防支援担当者

CareServComp

介護予防サービス事業者

186

Kind

01

事業所種別

CE

187

Num

1234567890

事業所番号

ST

188

Name

○×介護予防サービス事業者

189

PhoneNo

190

SatelliteInf

191

id

192

1

1

Address

csc001

名称

ST

電話番号

TN

サテライト区分ST

10

ID 型：HcareD から指される

神奈川県横浜市泉区○○町

所在地

AD

193

zip

245−００００

(ST)

194

state

神奈川県

(ST)

195

city

横浜市泉区

(ST)

196

strt

○○町

(ST)

ServCont

3421

サービス内容CE

199

UnitNum

1022

単位数

NM

200

ClsPayMaxSubj

Y

限度額適用対象

CE

2

201

ServCls15

サービス種類CE

8

202

UnitPrice

10.18

単価

MO

203

id

ps001

ID 型：GrantService から指される

197

0

unbounded

PS_Service

サービス

198

27

9

１．５．予防サービス提供票情報のタグセット構造（データ項目構造）
minOccurs

maxOccurs

項番1

unbounded

1
2

L1

L2

L3

L4

L5

L6

L7

属性

MsgPack

クラス名

ID
Status5xxxxxx

ID

ST

N

ステータス

CE

コメント

ST

Note
1

型

CareServ
Date

2006-09-01

対象年月

DT

8

AssrConf

123456

保険者確認

ST

9

MDate

2006-09-01

作成年月日

DT

10

RepDate2006-04-01

届出年月日

DT

11

Note

こ れ は 提 供 票 サ ン プル 用 のXML インスタンスです。

コメント

ST

12

refHomeHelper
1

1

hh001

Insr

IDREF 型：HomeHelper を指す
被保険者認定14

Authorized

Y

認定済

CE

15

LimitDate

2006-09-30

有効期限

DT

16

Num

0123456789

番号

ST

17

IssueDate

2006-04-01

交付年月日

DT

PayPercent

90

給付率

NM

18
19

0

1

5

居宅介護サービス

7

13

表

連携情報

4

1

属性名

通信用梱包
CarePlan

3

6

サンプル

Assr

保険者

20

Num

123456

番号

ST

21

Name

介護市

名称

ST

28

2

22

1

1

Assd

被保険者

23

Birthday

24

Sex

25
26

1932-10-02

生年月日

DT

M

性別

CE

電話番号

TN

住所

AD

PhoneNo0

1

神 奈 川県 介 護市 介 護 区 中 田
890

Address27

zip

212-8567

(ST)

28

state

神奈川県

(ST)

29

city

介護市介護区

(ST)

30

strt

中田 890

(ST)

31

1

1

Name

介護太郎

氏名

PN

32

fmn

介護

(ST)

33

gvn

太郎

(ST)

34

0

1

NameKana

35
36
37

0

unbounded

カイゴタロウ
fmn

カイゴ

gvn

タロウ

HomeCareHist

氏名フリガナ

PN
(ST)
(ST)

居宅介護支援事業者履歴

38

CorpName

介護市地域包括支援センター

事業所名称

ST

39

RepDate2006-02-20

届出年月日

DT

CE

40

0

unbounded

CareFaclHist

介護保険施設等履歴41

FaclKind

種類

42

FaclName

名称

ST

43

InDate入所入院年月日DT

退所退院年月日DT

44
45

OutDate1

1

1

CareNec

6

要介護認定

46

Rank

12

要介護状態区分

CE

47

CertDate

2006-04-01

認定年月日

DT

48

LifeTime.stdt

2006-04-01

有効期間

DR(TS)

49

LifeTime.eddt

2006-09-30

有効期間

DR(TS)

297

50

認定審査会意見ST

LimitCont

制限内容

ST

53

ServCont

サービス内容54

LifeTime.stdt

期間DR(TS)

55

LifeTime.eddt

期間

DR(TS)

56

PayPercent

給付率

NM

51

JudgeNote0

unbounded

PayLimit

給付制限

52

57

0

特になし

1

PayMaxCE

居宅サービス限度額

58

Base

19480

基準額

NM

59

LifeTime.stdt

200６-04-01

期間

DR(TS)

LifeTime.eddt

2006-09-30

期間

DR(TS)

60
61

0

unbounded

ClsPayMax

種類支給限度額

62

ServCls34

サービス種類CE

63

ClsBasisPay

100

基準額

NM

65

ServUnit

22807

単位数

NM

66

ClsLimOvrU

22207

種類基準超単位数

NM

67

ClsLimFixU

600

種類基準内単位数

NM

68

DivLimOvrU

0

区分基準超単位数

NM

69

DivLimFixU

600

区分基準内単位数

NM

70

InsTotal

6330

保険対象総額MO

71

InsPay

5696

保険給付額

MO

72

InsOwnPay634

保険対象利用者負担

MO

AllOwnPay

249686

全額負担利用者負担

MO

64

0

1

DivPayMaxMng

0unbounded

8

区分支給限度管理

73
74

9ClsPayMaxMng

種類別支給限度管理

75

TokuchiSubj

Y

特地加算対象CE

2

76

ServCls15

サービス種類CE

877

TotalUnit

3400

合計単位数

NM

30

78

LimOvrUnit

200

限度超単位数79

ClsPayMaxSubj

Y

限度額適用対象

CE

80

ServUnit

3400

単位数

NM

81

ClsLimOvrU

3200

種類基準超単位数

NM

82

ClsLimFixU

200

種類基準内単位数

NM

83

DivLimOvrU

0

区分基準超単位数

NM

84

DivLimFixU

200

区分基準内単位数

NM

85

InsTotal2036

保険対象総額MO

86

InsPay

1832

保険給付額

MO

87

InsOwnPay

204

保険対象利用者負担

MO

AllOwnPay

32575

全額負担利用者負担

MO

88
89

0

1

AnotherDivPayMaxMng

NM

他区分支給限度管理

90

ServUnit

19407

単位数

NM

91

ClsLimOvrU

21642

種類基準超単位数

NM

92

ClsLimFixU

415

種類基準内単位数

NM

93

DivLimOvrU

0

区分基準超単位数

NM

94

DivLimFixU

415

区分基準内単位数

NM

95

InsTotal4294

保険対象総額MO

96

InsPay

3864

保険給付額

MO

97

InsOwnPay

430

保険対象利用者負担MO

98

AllOwnPay27111

全額負担利用者負担

MO

前月までの利用日数NM

当月計画利用日数NM

累積利用日数

NM

99

0

1

SStyDays

短期入所利用日数100

LstMonthUseDays

101

ThisMonthPlanUseDays 3

102

SumUseDays

31

10

13

2

103

0

unbounded

PubPay

公費給付
Cls

サービス種類CE

105

Percent

給付率

NM

106

IssueDate

交付年月日

DT

107

PayNo

公費負担者番号ST

PayName

公費負担者名称

ST

選択

104

108
109
110
111
112

Benef iciaryNo

受給者番号

ST

LifeTime.stdt

有効開始日

DT

有効終了日

DT

LifeTime.eddt
0unbounded

OwnPayMax

自己負担上限113

Detail

内容

ST

114

PayMax

金額

MO

日付

DT

要介護状態区分

CE

115

1

1

CareRankHist_First

状態履歴_初回

116
117
118

0

1

8

Date

2006-04-01

Rank

12

CareRankHist_Recent7

状態履歴_最新

119

Date

日付

DT

120

Rank

要介護状態区分

CE

7

2

121

1

unbounded

HcareD

居宅介護サービス内容

122

InsrSubj

Y

保険対象

CE

123

PlanTotal

4

予定合計回数NM

124

ResultTotal

4

実績合計回数NM

125

DisUnit715

割引後単位数NM

126

Percent

割引率

NM

127

refCareServComp

csc001TimeScale.stdt

11:00:00.00

1280unbounded

DailyService_Plan

IDREF 型：CareServComp を指す
日毎サービス提供_予定

129

32

提供時間帯

DR(TS)

130

TimeScale.eddt

17:00:00.00

131

Date

2006-09-04

日付

DT

132

DayW

TUE

曜日

CE

133

Count

1

回数

NM

134

id

135

0

unbounded

dsp001

DailyService_Result

提供時間帯

DR(TS)

ID 型：DailyService_Result から指される
日毎サービス提供_実績

136

TimeScale.stdt

11:00:00.00

提供時間帯

DR(TS)137

TimeScale.eddt

17:00:00.00

提供時間帯

DR(TS)

138

Date

2006-09-04

日付

DT

139

DayW

TUE

曜日

CE

140

Count

1

回数

NM

141

refPlandsp001142

0

1NoGrantService

144
145

0

1

1

unbounded

ServCls
ServCont
GrantService

サービス種類ST

サービス内容ST

給付対象サービス

146
147

IDREFS 型：DailyService_Plan を指す
給付対象外サービス

選択

143

refPS_Service

ps001

HomeHelperOff ice

IDREF 型：PS_Service を指す
居宅介護支援事業者

148

Num

0000000043

事業所番号

ST

149

Name

介護市居宅介護支援センタ

名称

ST

150

PhoneNo(1234)1234-1234

電話番号

TN

151

1

1

Address

所在地

AD

152

zip

(ST)

153

state

(ST)

154

city

(ST)

155
156

strt
1

unbounded

3(ST)

HomeHelper

居宅介護支援担当者

157

id

33

hh001

ID 型：CareServ から指される

3

158

1

1

Name

介護花子

氏名

PN

159

fmn

(ST)

160

gvn

(ST)

161

1

unbounded

PrevHomeHelperOffice

地域包括支援センター

162

Num

0000000043

事業所番号

163

Name

介護市地域包括支援センター

名称

ST

164

PhoneNo(1234)1234-1234

電話番号

TN

所在地

AD

165

1

1

Address

ST

166

zip

(ST)

167

state

(ST)

168

city

(ST)

169

strt

(ST)

170

1

unbounded

HomeHelper

居宅介護支援担当者

171
172

id
1

1

Name

ID 型：CareServ から指される

介護花美

173

氏名

fmn

174
175

hh002

gvn
0

unbounded

PN
(ST)
(ST)

CareServComp

居宅介護サービス事業者

176

Kind

01

事業所種別

CE

177

Num

1234567890

事業所番号

ST

178

Name

訪問介護センタ

名称

ST

179

PhoneNo

電話番号

TN

180

SatelliteInf

サテライト区分

ST

所在地

AD

181
182

id
1

1

Address

csc001
神奈川県横浜市泉区○○町

ID 型：HcareD から指される

183

zip

245−００００

(ST)

184

state

神奈川県

(ST)

185

city

横浜市泉区

(ST)

34

10

186

strt

○○町

ServCont

3421

サービス内容CE189

UnitNum

1022

単位数

NM

190

ClsPayMaxSubj

Y

限度額適用対象

CE

2

191

ServCls15

サービス種類CE

8192

UnitPrice

10.18

単価

MO

193

id

ps001

187

0

unbounded

PS_Service

(ST)
サービス

188

194

35

ID 型：GrantService から指される

9

２．関連情報
上記で定義した構造のメッセージを生成する際の各タグの情報を記載する。
２．１．項目辞書
タイプ タグ要素
要素

○

要素名

属性名

Address

書式

default

fixed

nillable

use

st_el

属性

Addresscity

stoptional

属性

Addressstate

stoptional

属性

Address

strt

stoptional

属性

Addresszip

stoptional

Assesment

Attentionstrequired

Agreement

Date

st

required

要素

○

属性
属性

Agreement

要素○

Assesment

要素○

AnotherDivPayMaxMng

属性

AnotherDivPayMaxMng

AllOwnPaymorequired

属性

AnotherDivPayMaxMng

ClsLimFixU

nm

required

属性

AnotherDivPayMaxMng

ClsLimOvrU

nm

required

属性

AnotherDivPayMaxMng

DivLimFixU

nm

required

属性

AnotherDivPayMaxMng

DivLimOvrU

nm

required

属性

AnotherDivPayMaxMng

InsOwnPaymorequired

属性

AnotherDivPayMaxMng

InsPaymorequired

属性

AnotherDivPayMaxMng

InsTotalmorequiredAnotherDivPayMaxMng

ServUnit

nm

requiredAddstrequired

属性
要素○

AnyTime

属性
要素

AnyTime

○

Assd

属性

Assd

age

mo

optional

属性

Assd

Birthdaydt

optional

属性

Assd

PhoneNotn

optional

属性

Assd

Sex

ce01

optional

要素

○

Assr

属性

Assr

Name

st

required

属性

Assr

Num

st

required要素

CalcReason

属性

CalcReason

要素

○

st_el
cd

ce12

required

CareFaclHist

属性

CareFaclHist

FaclKindce06

required

属性

CareFaclHist

FaclNamestrequired

属性

CareFaclHist

InDatedt

required

CareFaclHist

OutDatedt

required

属性
要素○

CareNec

属性

CareNec

CertDatedt

required

属性

CareNec

JudgeNotestoptional

属性

CareNec

LifeTime.eddt

ts_d

required36

属性

CareNec

LifeTime.stdt

ts_d

required

属性

CareNec

Rank

ce07

required
required要素○

CarePlan

属性

CarePlan

ID

st

属性

CarePlanNotestoptional

属性

CarePlanStatusce05

required

CareRankHist_First

Date

dt

required

CareRankHist_First

Rank

ce07

required

要素

○

属性
属性
要素

○

CareRankHist_First

CareRankHist_Recent

属性

CareRankHist_Recent

Date

dt

required

属性

CareRankHist_Recent

Rank

ce07

required要素○

CareServ

属性

CareServ

AssrConf

st

optional

属性

CareServ

Datedt

required

属性

CareServ

MDate

dt

optional

属性

CareServ

No

strequired

属性

CareServ

Notestoptional

属性

CareServ

refHomeHelper

IDREF

required

属性

CareServ

RepDatedt

optional

属性

CareServ

Statusce11

required

属性

CareServ

TotalPlanstrequired

属性

CareServ

UserReqstrequired要素○

CareServComp

属性

CareServComp

idID

required

属性

CareServComp

Kind

ce10

required

属性

CareServComp

Name

st

required

属性

CareServComp

Num

st

required

属性

CareServComp

PhoneNotn

required

CareServComp

SatelliteInfstrequiredDatedtrequiredDatedtrequired

属性
要素○

CheckList

要素○

ChgHist_First
ChgHist_First

属性
要素

○

ChgHist_Recent

属性
要素

ChgHist_Recent○

ClsPayMax

属性

ClsPayMax

ClsBasisPaynm

required

属性

ClsPayMax

ServCls

ce08

required

要素○

ClsPayMaxMng

属性

ClsPayMaxMng

AllOwnPaymorequired

属性

ClsPayMaxMng

ClsLimFixU

nm

required

属性

ClsPayMaxMng

ClsLimOvrU

nm

required

属性

ClsPayMaxMng

ClsPayMaxSubj

ce02

required

属性

ClsPayMaxMng

DivLimFixU

nm

required

属性

ClsPayMaxMng

DivLimOvrU

nm

required37

属性

ClsPayMaxMng

InsOwnPaymorequired

属性

ClsPayMaxMng

InsPaymorequired

属性

ClsPayMaxMng

InsTotalmorequired

属性

ClsPayMaxMng

LimOvrUnit

nmrequired

属性

ClsPayMaxMng

ServCls

ce08

required

属性

ClsPayMaxMng

ServUnit

nm

required

属性

ClsPayMaxMng

TokuchiSubj

ce02

required

属性

ClsPayMaxMng

TotalUnitnm

required要素○

Communication

属性

Communication

Check

ce13

required

属性

Communication

Conditionstrequired

属性

Communication

Prob

st

requiredCommunication

UserReqstrequired

属性
要素○

DailyAct

属性

DailyAct

Detailstrequired

属性

DailyActTimeBand.eddt

ts_t

optional

属性

DailyActTimeBand.stdt

ts_t

optional

要素○

DailyLife

属性

DailyLife

Check

ce13

required

属性

DailyLife

Conditionstrequired

属性

DailyLife

Prob

st

required

DailyLife

UserReqstrequired

属性
要素○

DailyService_Plan

属性

DailyService_Plan

Count

nm

required

属性

DailyService_Plan

Date

dt

required

属性

DailyService_Plan

DayW

ce03

required

属性

DailyService_Plan

idID

required

属性

DailyService_Plan

TimeScale.eddt

ts_t

optional

属性

DailyService_Plan

TimeScale.stdt

ts_t

optional

要素○

DailyService_Result

属性

DailyService_Result

Count

nm

required

属性

DailyService_Result

Date

dt

required

属性

DailyService_Result

DayW

ce03

required

属性

DailyService_Result

refPlan

IDREFS

optional

属性

DailyService_Result

TimeScale.eddt

ts_t

optional

属性

DailyService_Result

TimeScale.stdt

ts_t

optional

DailyWork

Timeband.eddt

ts_t

required

DailyWork

Timeband.stdt

ts_t

required

要素

○

属性
属性
要素

○

DailyWork

Depression

属性

Depression

Questionmorequired

属性

Depression

TotalQuestionmorequired

要素○

DivPayMaxMng

属性

DivPayMaxMng

AllOwnPaymorequired

属性

DivPayMaxMng

ClsLimFixU

nm

required38

属性

DivPayMaxMng

ClsLimOvrU

nm

required

属性

DivPayMaxMng

DivLimFixU

nm

required

属性

DivPayMaxMng

DivLimOvrU

nm

required

属性

DivPayMaxMng

InsOwnPaymorequired

属性

DivPayMaxMng

InsPaymorequired

属性

DivPayMaxMng

InsTotalmorequired

DivPayMaxMng

ServUnit

nm

required

属性
要素○

Exercise

属性

Exercise

Check

ce13

required

属性

Exercise

Conditionstrequired

属性

ExerciseProbstrequired

属性

Exercise

UserReqstrequiredForget

QuestionmorequiredForgetTotalQuestionmorequired
required

要素

○

属性
属性
要素

○

ForgetGetInf

属性

GetInf

ID

st

属性

GetInfNote

stoptional

属性

GetInfStatusce05

requiredrefPS_Service

IDREF

required

要素

○

要素

GrantService
GrantService

属性○

HcareD

属性

HcareDClassOLstrequired

属性

HcareD

DisUnitnm

required

属性

HcareDFreq

strequired

属性

HcareD

InsrSubj

ce02

required

属性

HcareD

Outlinestrequired

属性

HcareD

Percent

nm

required

属性

HcareD

Periodstrequired

属性

HcareD

PlanTotal

nm

required

属性

HcareD

refHelp_Target

IDREFSrequired

属性

HcareD

ResultTotal

nm

required要素○

HealthManagement

属性

HealthManagement

Check

ce13

required

属性

HealthManagement

Conditionstrequired

属性

HealthManagement

Prob

st

required

HealthManagement

UserReqstrequired

属性
要素○

Help_Target

属性

Help_Target

idID

required

属性

Help_Target

LongT

st

required

属性

Help_Target

LTPeriodstrequired

属性

Help_Target

refProb

IDREFSrequired

属性

Help_Target

ShortTstrequired

属性

Help_Target

STPeriodstrequired

要素○

HomeCareHist

39

属性

HomeCareHist

CorpNamestrequired

属性

HomeCareHist

RepDatedt

requiredidID

required

要素

○

要素

HomeHelper
HomeHelper

属性○

HomeHelperOffice

属性

HomeHelperOffice

Name

st

required

属性

HomeHelperOffice

Num

st

required

属性

HomeHelperOffice

PhoneNotn

required

InfSysPasswdstrequired

InfSysUserIDstrequired

要素

○

属性
属性
要素

○

InfSys

Insr

属性

Insr

Authorized

ce02

required

属性

Insr

IssueDatedt

optional

属性

Insr

LimitDatedt

optional

属性

Insr

Num

st

optional

属性

Insr

PayPercent

nm

optional

LackExercise

Questionmorequired

LackExercise

TotalQuestionmorequired

要素

○

属性
属性
要素

○

LackExercise

LifeTarget

属性

LifeTarget

DayTargetstrequired

属性

LifeTarget

YearTargetstrequired要素○

MsgPack

要素

○

Name

st_el

属性

Name

fmn

st

optional

属性

Name

gvn

st

optional

要素

NameKana

属性

NameKana

fmn

stoptional

NameKana

gvn

stoptional

NoGrantService

ServClsstrequired

NoGrantService

ServContstrequired

属性
要素

○

属性
属性
要素

○

st_el

NoGrantService

Nutrition

属性

Nutrition

Questionmorequired

属性

Nutrition

TotalQuestionmorequired

Oral

Questionmorequired

Oral

TotalQuestionmorequired

要素

○

属性
属性
要素

○

Oral

OwnPayMax

属性

OwnPayMax

Detailstrequired

属性

OwnPayMax

PayMaxmo

required要素○

PayLimit

属性

PayLimit

LifeTime.eddt

ts_d

required

属性

PayLimit

LifeTime.stdt

ts_d

required40

属性

PayLimit

LimitContstrequired

属性

PayLimit

PayPercent

nm

optional

PayLimit

ServCont

ce09

required

属性
要素○

PayMax

属性

PayMaxBase

nm

required

属性

PayMax

LifeTime.eddt

ts_d

required

PayMax

LifeTime.stdt

ts_d

required

属性
要素

○

Point

属性

Point

Detailstrequired

属性

Point

id

ID

required

Point

refTarget

IDREFSrequired

Detailstrequired
required

属性
要素○

Policy要素○

PresentPlan
PresentPlan

属性
要素

○

PrevHomeHelperOffice

属性

PrevHomeHelperOffice

Name

st

属性

PrevHomeHelperOfficeCommentst

属性

PrevHomeHelperOffice

Num

st

required

属性

PrevHomeHelperOffice

PhoneNotn

required

Prob

Detailstrequired

Prob

id

ID

required

要素

○

属性
属性
要素

○

Prob

ProbMeasure

属性

ProbMeasure

TargetMeasurestrequired

属性

ProbMeasure

TotalProbstrequired

属性

ProbMeasure

UserReqstrequired

属性

ProbMeasureidID

required

要素○

PS_Service

属性

PS_Service

ClsPayMaxSubj

ce02

required

属性

PS_Service

idID

required

属性

PS_Service

ServCls

ce08

required

属性

PS_Service

ServCont

ce09

required

属性

PS_Service

UnitNum

nm

required

属性

PS_Service

UnitPricemorequired要素○

PubPay

属性

PubPayBeneficiaryNo

stoptional

属性

PubPayCls

ce08

required

属性

PubPayIssueDatedt

optional

属性

PubPay

LifeTime.eddt

ts_d

optional

属性

PubPay

LifeTime.stdt

ts_d

optional

属性

PubPayPayNamest

optional

属性

PubPayPayNostoptional

PubPayPercent

nm

requiredClassOLstrequired

属性
要素
属性

○

ServKind
ServKind41

属性

ServKind

Periodstrequired

属性

ServKindNamestrequired

属性

ServKind

refSupportPlan

IDREFSrequired

属性

ServKind

refCareServComp

IDREF

optional

要素○

SStyDays

属性

SStyDays

LstMonthUseDays

nm

required

属性

SStyDays

SumUseDays

nm

required

属性

SStyDays

ThisMonthPlanUseDaysnm

required

要素○

SupportPlan

属性

SupportPlan

OtherSupport

strequired

属性

SupportPlan

Outlinestrequired

属性

SupportPlan

idID

required

SupportPlan

refPoint

IDREFSrequired

属性
要素○

Target

属性

TargetDetailstrequired

属性

Targetid

IDrequired

属性

TargetrefProbMeasure

IDREFSrequired

Detailstrequired

要素

○

要素

TotalPlan
TotalPlan

属性
○

Week

属性

Week

Day

ce03

required属性

Week

Timeband.eddt

ts_t

required属性

Week

Timeband.stdt

ts_t

required

要素○

Withdraw

属性

Withdraw

Questionmorequired

属性

Withdraw

TotalQuestionmorequired42

２．２．データ形式一覧

43

２．３．コード体系
コード
表番号

１

2
3

内容
性別（USER̲0001）
F Female
M MaleO Other
U Unknown
Boolean（HL7̲0136）
Y Yes
N No
曜日（HL7̲0267）

25
26
31
32
33
34
35
36

4

5

6

7

8

SAT Saturday
SUN Sunday
MON Monday
TUE Tuesday
WED Wednesday
THU Thursday
FRI Friday
処理内容（HL7̲0323）
A Add
D Delete
U Update
処理ステータス
N 新規
D 削除
U 変更
OK 正常
NG 異常
介護保険施設種類
51 介護老人福祉施設
52 介護老人保健施設
53 介護療養医療施設
要介護状態区分
01 非該当11 要支援 1
12 要支援 2
21 1
22 2
23 3
24 4
25 5
サービス種類
11 訪問介護12 訪問入浴介護
13 訪問看護14 訪問リハビリテーション
15 通所介護16 通所リハビリテーション
17 福祉用具貸与
21 短期入所生活介護
22 短期入所療養介護（介護老人保健施設）
23 短期入所療養介護（介護療養型医療施設等）
24 介護予防短期入所生活介護

44

37
38

10

地域密着型特定施設入居者生活介護
介護予防認知症対応型生活介護(短期利用以外)
認知症対応型共同生活介護(短期利用)

41
42
43
44

介護予防認知症対応型共同生活介護(短期利用)
特定福祉用具販売
住宅改修
居宅介護支援特定介護予防福祉用具販売

45
46
51
52
53
59
61
62
63
64
65

介護予防住宅改修
介護予防支援介護老人福祉施設サービス
介護老人保健施設サービス
介護療養型医療施設サービス
特定入所者介護予防サービス等
介護予防訪問介護
介護予防訪問入浴介護
介護予防訪問介護
介護予防訪問リハビリテーション
介護予防通所介護66

介護予防通所リハビリテーション

67
71
72
73

介護予防福祉用具貸与
夜間対応型訪問介護
認知症対応型訪問介護
小規模多機能型居宅介護39

9

介護予防短期入所療養介護(介護老人保健施設)
介護予防短期入所療養介護(介護療養型医療施設等)
居宅療養管理指導痴呆対応型共同生活介護
特定施設入所者生活介護
介護予防居宅療養管理指導
介護予防特定施設入居者生活介護

74 介護予防認知症対応型通所介護
75 介護予防小規模多機能型居宅介護81~ その他（市町村特別給付等）
サービス内容[サービス内容]のコード体系(4 桁)に順ずる
事業所種別
01 社会福祉法人（社協以外）
02 社会福祉法人（社協）03 医療法人
04 民法法人（社団・財団）
05 営利法人
06 非営利法人（ＮＰＯ）
07 農協
08 生協
09 その他法人
10 地方公共団体（都道府県）
11 地方公共団体（市町村）
12 地方公共団体（広域連合・一部事務組合等）
13 非法人99 その他

11

12

13

計画書ステータス
11 初回
12 紹介
21 継続
算定理由
1 一人暮らし2 家族等が障害、疾病等
3 その他
領域における課題の有無
1 あり
2 なし

45

＜参考資料＞
本メッセージ定義作成あたり、参考とした介護帳票を以下に示す。
なお、介護予防サービスの帳票は、標準様式が規定されていないため、下記の推奨様式、及び既存のサービス提供票を参考に定義を作成している。
① 居宅介護サービス計画書（１）② 居宅介護サービス計画書（２）③ 週間サービス計画書④ サービス提供票⑤ サービス提供票 別表⑥ 介護予防サービス・支援計画書

46

①居宅サービス計画書（１）47

②居宅サービス計画書（２）48

③週間サービス計画書

49

④サービス提供票50

⑤サービス提供票 別表51

⑥介護予防サービス・支援計画書
介護予防サービス支援計画表
初回・紹介・継続

Ｎｏ．
利用者名

様 (男・女)歳 認定年月日年

月

計画作成者氏名

日 認定の有効期間

年

月

日〜

年

月

認定済・申請中

要支援１・要支援２

地域支援事業日

委託の場合：計画作成者事業者・事業所名及び所在地（連絡先）

計画作成（変更）日

年

月日（初回作成日）

年月日）

担当地域包括支援センター：

目標とする生活1日

1年

アセスメント領域と課題に対する

本人・家族の 領域における課題

現在の状況

意欲・意向

総合的課題

（背景・原因）運動・移動について□有 □無日常生活(家庭生活)につ□有 □無目標と具体策支援計画

具体策についての意向

目標

本人・家族

の提案

支援のポイント

1.

1.

1.

1.

2.

2.

2.

2.

本人等のセルフケアや家族の支援、インフォーマルサービス

介護保険サービス

サービス

又は地域支援事業

種別

事業所

期間

（ ）

（ ）

いて
□有 □無

社会参加、対人関係・コ

目標についての（ ）ミュニケーションにつ
いて

3.

3.

3.
（ ）

健康状態について□主治医意見書、健診結果、観察結果等を踏まえた留意点【本来行うべき支援が実施できない場合】
妥当な支援の実施に向けた方針

基本チェックリストの(該当した項目数)／（質問項目数）を記入して下さい
地域支援事業の場合は必要な事業プログラムの枠内の数字に○印をつけて下さい

予防給付 または地域支援事業3.

□有 □無健康管理について

運動
不足

栄養
改善

口腔内
ケア

閉じこも
り予防

物忘れ
予防

うつ
予防

／5

／2

／3

／2

／3

／5

総合的な方針：生活不活発病の改善予防のポイント

計画に関する同意【意見】

上記計画について、同意いたします。

地域包括支援
セ ン タ 【確認印】
ー

平成

52

年

月

日 氏名

印

53