Más contenido relacionado IdCon #9 番号制度と情報連携基盤5. 情報をマッチングする基盤(情報連携基盤)の要件
1. 必要な情報連携ができること
かならずしもICカードを必要としないこと
2. 国家による「個人に関わる情報」の集中管理をしえないこと
3. 情報保有機関の結託による不正な名寄せと、それによるプ
ライバシー侵害が起きないようにすること
4. (特に複数の機関からの)情報漏洩により、第三者による不
正な名寄せと、それによるプライバシー侵害が起きないよう
にすること
4
7. 6 りよ 」~察考たけ向に入導ので本日~向動のDI民国るけおに外海「告報会究研会学 所究研済経会社際国
(参考)オーストリアセクトラルモデルによる情報連携[1/2]
8. 7 りよ 」~察考たけ向に入導ので本日~向動のDI民国るけおに外海「告報会究研会学 所究研済経会社際国
(参考)オーストリアセクトラルモデルによる情報連携[2/2]
11. 10 りよ」較比のと案化素簡と案行現式方携連号番「 ブサーザーユ術技盤基携連報情
WG
12. 論点① フラットモデルvsセクトラルモデル
① 複雑さ=セキュリティではないし、「番号」でデータを
紐付ければいいお。
② 複雑な仕組みにするとシステム費用が増えるので
簡単な仕組みが良いお。
フラット派
① すべてのデータを「番号」でやり取りするのは、時の国家権
力や情報保有機関同士の結託により、簡単に名寄せされ、
本人の望まない自己像の形成が行われてしまう可能性が
あるだろ、jk。
② 任意の2機関からデータ漏洩が起きた場合に、第三者によ
り、簡単に名寄せされ、本人の望まない自己像の形成が行
われてしまう可能性があるだろ、jk。
③ 「複雑」の一言で片付けるのは仕組みがわかってないから。
脅威分析の上、費用にあった仕組みを取る必要があるの セクトラル派
はもちろんだが、プライバシー保護の仕組みは必須だろ、jk。
11
13. 12 りよ」較比のと案化素簡と案行現式方携連号番「 ブサーザーユ術技盤基携連報情
WG
14. 13 りよ」較比のと案化素簡と案行現式方携連号番「 ブサーザーユ術技盤基携連報情
WG
15. そもそも…
番号って共通である必要あるの?
番号って共通である必要あるの?
って共通である必要あるの
14
16. そもそも番号って共通である必要あるの?
医療受診と高額療養費申請の流れ
【源泉徴収事業者】
調書
医療受診
納税
【国税庁、自治体】
グロブ闘奮座講信通 得取格資の務事療医 ンャキーユ:典出の絵
http://www.universalcare.jp/receipt.html 15
17. そもそも番号って共通である必要あるの?
診療報酬支払い審査に所得情報を利用して、払い戻し額を自動判別するケース
番号
配布
番号
【基礎自治体】
番号
番号
番号
【源泉徴収事業者】
番号
番号
番号
番号
調書
番号
番号
付番
医療受診
納税
番号
【国税庁、自治体】
情報連携基盤
グロブ闘奮座講信通 得取格資の務事療医 ンャキーユ:典出の絵
http://www.universalcare.jp/receipt.html 16
22. 論点② ゲートウェイモデルvsアクセストークンモデル
① 情報連携基盤の中をデータを通すようにすること
で、情報保有機関どうしの結託により名寄せ用の
データ埋め込みを防ぐことができるお。
② Peer to Peerの連携の場合、テストパターンが膨大
になるし、各々が勝手に連携の仕組みを決めてし
まって収集がつかなくなるお。
ゲートウェイ派
① ゲートウェイモデルでは、国家によるデータ集中管
理の問題が発生する。「集中管理しえない事」が
要件であり、消せばいい(集中管理しないからい
い)という問題ではないだろ、jk。
② 標準化すればテストパターンは膨大にはならない
だろ。逆に、各々のニーズをすべて中央のゲート
ウェイの改修により対応するシステムでは、柔軟 アクセストークン派
性に書ける上、費用が膨大になるだろ、jk。
21
23. 論点② ゲートウェイモデルvsアクセストークンモデル
① 情報連携基盤の中をデータを通すようにすること
で、情報保有機関どうしの結託により名寄せ用の
データ埋め込みを防ぐことができるお。
② Peer to Peerの連携の場合、テストパターンが膨大
そもそも、
そもそも、
になるし、各々が勝手に連携の仕組みを決めてし
まって収集がつかなくなるお。
ゲートウェイ派 の技術をどうこう言うフェーズではなく、
個別の
個別 技術をどうこう うフェーズではなく、
をどうこう言
どの様な情報連携の仕組みとすべきか、
どの様 情報連携の仕組みとすべきか、
みとすべきか
① ゲートウェイモデルでは、国家によるデータ集中管
評価軸を
評価軸を出す方が先では では?
理の問題が発生する。「集中管理しえない事」が?
要件であり、消せばいい(集中管理しないからい
(評価軸の例) http://www.cas.go.jp/jp/seisaku/jouhouwg/renkei/dai6/siryou3_14.pdf
い)という問題ではないだろ、jk。
② 標準化すればテストパターンは膨大にはならない
だろ。逆に、各々のニーズをすべて中央のゲート
ウェイの改修により対応するシステムでは、柔軟 アクセストークン派
性に書ける上、費用が膨大になるだろ、jk。
22