情報技術選択における技術参照モデルと非技術的側面

高田斑平成１５年度報告書ドラフト

Table of Contents

1. 概要

2. 情報技術選択と技術参照モデル

選択と分類

分類＝モデル

エンタープライズ・アーキテクチャと技術参照モデル

Zachman Framework
エンタープライズ・アーキテクチャ
Federal Enterprise Architecture (FEA)
Technical Reference Model (TRM)

今後の課題

3. 情報技術選択の非技術的側面

資材調達型の導入方式の問題

医療機関における情報システム部門の不在

エンタープライズ・アーキテクチャ＋医療情報技師＋ITアウトシーシング＝プロセスとしての電子カルテ導入

エンタープライズ・アーキテクチャ(再訪)
医療情報技師
ITアウトソーシング
情報技術選択との関係

4. まとめ

Bibliography

Chapter�1.�概要

電子カルテを実装する為には、各種の情報技術の中から適切なものを選択しなければならない。情報技術の選択を行う為にはそれらが適切に分類されている必要がある。例えば、ある機能を実装する際に用いる情報を選択する際に、製品と規格を選択枝とするのは誤りであるが、複雑な情報技術についてはそのような事が頻繁に起こっている。情報技術について適切な分類を行うことは困難であるばかりではなく、分類方法についてのコンセンサスが得られなければならない。可能であれば、分類方法／分類結果を新たに考え出すよりは、既に存在しコンセンサスが得られているものを再利用することが望ましい。

情報技術の分類方法／分類結果として、米国連邦政府の電子政府化政策の過程で開発された連邦エンタープライズ・アーキテクチャFederal Enterprise Architecture:FEA)の中で技術参照モデル(Technical Reference Model:TRM)が策定されており、これを情報技術の分類の基準とするのが望ましいことがわかった。今後の課題として、FEA/TRMを再利用して電子カルテの技術参照モデルを開発する。

情報技術の選択を行う上では、選択対象としての情報技術自体の分析／評価だけでなく、非技術的側面として情報技術を取り巻く環境についても検討しなければならない。非技術的側面とは情報技術自身ではなく、情報技術や情報システムが開発され活用されるための環境であり、組織の構造と運営、人間の心理、経済や法律などの側面である。

とりわけ、電子カルテが医療機関に導入される過程がスムーズでなければ、電子カルテの開発自体に成功したとしても、プロジェクトとしては失敗である。そこで現状における電子カルテやオーダー・エントリー・システムのような大規模な情報システムの導入過程の問題について分析を行い、対策としてエンタープライズ・アーキテクチャ等の導入を提案する。

Chapter�2.�情報技術選択と技術参照モデル

Table of Contents

選択と分類

分類＝モデル

エンタープライズ・アーキテクチャと技術参照モデル

Zachman Framework
エンタープライズ・アーキテクチャ
Federal Enterprise Architecture (FEA)
Technical Reference Model (TRM)

今後の課題

選択と分類

電子カルテを実装する為には、各種の情報技術の中から適切なものを選択しなければならない。選択は候補の一覧の中からの選択となるが、候補に洩れや混入があると適切な選択は行えない。候補の一覧の作成を行うには、対象分野についての分類方法を定義し、それに従い実在するものを分類しなければならない。適切な分類がなされていないと、本来、比較／選択を行うべきでない候補間での選択を行ってしまう可能性がある。

特に企業が提示する資料では誤った比較などがしばしば見受けられる。例えば、あるアプリケーションの宣伝的仕様書に Microsoft 社の MSXML と W3C による DOM を比較し、MSXML の方が優れておりそのアプリケーションは MSXML を採用しているので優れた機能を持っている、という旨の記述があったとする。この例は情報技術に精通した者であれば誤った比較であると即座にわかる。DOM、MSXML は XML 文書を処理するソフトウェアに関するものであるが、DOM は各種の実装が共通に採用すべき「仕様」について記述した文書であるが、MSXML は DOM を大幅に拡張して実装した「製品」である。しかし、情報技術に精通していないものが仕様策定や製品の評価などを行う場合は、惑わされてしまうであろう。

従って情報技術に関する適切な分類方法と分類結果(以下「分類」と略す)が必要である。また、分類が複数存在しそれらが競合しているような状態はさらなる混乱を来す事になる。よって、少なくとも特定の分野においては、その分野における目的を達成する為に設計されたが共通の分類を持たなければならない。当然ながら、この分類は広くコンセンサスを得られたものでなければならない。この分類は、電子カルテのような情報システムの調達において、調達側は要求仕様書において採用を希望する情報技術を指定するため、開発側は自らの製品／サービスが採用した情報技術を提示するため共通に参照する重要な情報となる。

分類＝モデル

分類が単に分類結果だけを列挙するだけでは、分類の利用者が正しく理解できず誤用や悪用されるおそれがあり、コンセンサスも得られ難いであろう。分類には、背景、方法、根拠等について明確で分かりやすい説明が必要であある。また分類を十分に厳密性のあるものとするためには、分類を系統だった構造をもつ情報の集まりとして定義する必要がある。これらを達成することは即ち分類をモデルとして開発する事になる。

情報技術を分類するモデルを開発するという作業は、特定の業務や情報システムのモデルを開発するのは全く異なったより複雑なものであり、情報技術を分類する為の新たなモデルの開発には膨大な時間と労力がかかることが容易に予想できる。また、モデルのコンセンサスの獲得にも膨大な時間と労力が必要とことが予想できる。現実的には行政や学会による承認も必要となるであろうし、情報技術は国際的なものであるためそれは国際的でなければならない。何であれ新たなモデルを情報技術の世界に不用意に導入することを主張することは、NIH (Not Invented Here) 症候群の誹りを免れないであろう。よって、既にコンセンサスが得られているモデルが存在するのであればそれを再利用するのが望ましい。調査の結果、既にそのようなモデルが存在することがわかった。米国連邦政府の電子政府化政策の中で定められた EFA/TRM がそれである。

エンタープライズ・アーキテクチャと技術参照モデル

Zachman Framework

エンタープライズ・アーキテクチャ (Enterprise Architecture, EA)は、1987年に IBM Systems Journal に掲載された John. F. Zachman の論文「A Framework for Information Systems Architecuter」[1]が発端とされている。アーキテクチャ(建築術、建築学、建築様式、建物、構造、構成)という言葉を情報技術や情報システムの中で使うことは Zachman 以外にもあるが、それらはどちらかと言えば「建築様式」或は「構造」という対象物に対して使われる事が多い。一方 Zachman はこの論文の中で、建築物が作られる際にどのような図面や書類が作成され、それがを誰が作成し誰がそれを参照するかに注目した。アーキテクチャという言葉を建築術に対比して、情報システムを開発する過程について与えた。

Zachman は個人の邸宅の建築の過程を例にとり、建築主、建築家、建築業者、施工業者等など建築に関係する人々がそれぞれの立場による見方(perspective)に沿って各種の図面や帳票を作成するが、それらは目的や形式が異なる(unique) ものであって、工程に従って単純に各種の仕様を詳細化するのではないとしている。同じようなことは軍用航空機の開発でも行われていることを示し、複雑な工学的製品の構築ではこの考え方が一般的であることを示した。この(建築術という意味での)アーキテクチャは情報システムの開発にも適用できることを指摘した。

次に Zachman は、それぞれの立場による見方で作成される図面や帳票自体も１種類ではなく、英語に於ける疑問詞(What, How, Where, Who, When, Why)に答えるため、それぞれについての記述(types of description)が必要であることを指摘した。見方と記述の二つを軸とした Zachman Framework Matrix と呼ばれる表形式の枠組(Framework)を示し、枠を埋める個々の図面や帳票を記述することが情報システムを開発する上で有効であることを示した。

この枠組について理解する上で重要な点は、枠組自体はこのような表形式をとり、行としては立場による見方、欄としては対象の様相をとるという事だけを提示しているのであって、実際に行、欄としてどのようなものを取るかについては規定しておらず、枠の中に入る記述の仕方や構成要素についても何ら指定していないということである。これは、従来の情報システムの開発技法である段階的詳細化や処理の流れやデータの構造や流れなどの一つの様相を中心に据えそれ以外の様相を付属的なものと考える各種の手法と一線を画すものであった。

エンタープライズ・アーキテクチャ

Zachman によって示された枠組は後に Sowa によって企業組織(エンタープライズ)にも適用が可能であることが示された[2]。この枠組を情報システムに適用する場合と組織に適用する場合の違いは、情報システムに適用する場合は、通常新たなシステムを構築する過程に適用するので目標とする表による枠組が一つだけ作られるが、組織に適用する場合は、現在の状態(baseline, as-is)から将来の状態(target, to-be)への組織の再構築する過程に適用することになるので、二つの表による枠組が作られることになる。エンタープライズ・アーキテクチャは、二つの表による枠組を持つことが一つの特徴である。

組織に適用する場合はそれに伴う情報システムの導入或は更新が意図される。そもそもこの枠組自体が情報システムの開発の為に考案されたという背景もあるが、それ以上に重要なポイントは情報システムの導入を、従来のような情報システム部門主導の活動ではなく組織全体の活動としてとらえようという所にある。これは、従来型の情報システム導入が、情報システム部門とシステムを利用する業務部門による個々のプロジェクトとして行われて来たため、重複した機能を持ちながら相互運用性の無いシステムが組織内に多数導入されてしまったため、組織全体の業務の改革／効率化を妨げるばかりか、情報技術の進歩を享受できなくなったという失敗への反省と考えられる。また、従来の情報システムの開発では実装に用いられる情報技術の選択は設計工程の下流と位置付けられてきたが、エンタープライズ・アーキテクチャでは業務分析やシステム設計と並行で進められるものであり、特に新たな情報技術の導入がビジネスをどう変えるかということが注目される。よって情報技術の選択は個々の情報システムの開発者の独断で行われるのではなく、組織全体の戦略の一貫として行われることになる。

Federal Enterprise Architecture (FEA)

米国連邦政府 (Federal Government) における電子政府化に向けた情報システムの整備において、省庁毎の縦割りによる情報システム構築の弊害が指摘され、横断的な情報システムな構築を可能にする方法が必要とされた。各省庁の情報責任者 (CIO) による評議会 (CIO Council) は、それぞれの組織(エンタープライズ)の既存の情報資産を破棄して新たな情報システムを構築するのではなく、横断的、段階的、継続的な進化の過程を可能とする枠組(Federal Enterprise Architecture Framework, FEAF)を開発した[3]。 FEAF は Zachman の枠組を包含するより上位の全く異なった形の枠組である。FEAF は現在の業務／情報システムのアーキテクチャから目標とするアーキテクチャへの移行の為の枠組を示している。そしてそのアーキテクチャを記述する方法として Zachman の枠組を用いている。

FEAF に従って各省庁(エンタープライズ)は独自の EA の進化を行うわけであるが、Zachman の枠組の枠の中の記述がエンタープライズ毎に全く異なっていては FEAF が事実上機能しなくなってしまう。そこで概念や用語について共通に参照されるべきモデルが必要となる。そこで FEAPMO (Federal Enterprise Architecture Program Management Office)は参照モデル(Reference Model)として、５つの参照モデルの開発を行っている。

Technical Reference Model (TRM)

FEAPMO が定めた５つの参照モデルのうち、情報技術に関する各種の規格、仕様、技術について分類を行ったものが技術参照モデル(Technical Reference Model, TRM)[4]である。技術参照モデルは電子政府実現の上で省庁と市民(G2C)、省庁間(G2G)、省庁と企業(G2B)の間の情報のやり取りを支える為に用いられる各種の情報技術を階層的に分類している。分類された各情報技術については簡単な説明と情報元への URL が記載されており一種のカタログのようになっている。この様な資料を完全なものにする事は膨大な労力を必要とする。実際、現時点の技術参照モデルに列挙されている情報技術は完全に網羅されたものではなく説明も簡略なものである。しかし、このような資料が公的に示されることの意義は、内容が完全でないことのマイナスを補って余り大きい。

計算機が汎用機しかなかった時代、情報技術者は計算機に関わるハードウェア／ソフトウェアについて全般的な知識を持つことはそれほど困難ではなかった。しかし、今日では多様化した情報技術について全般的な知識を維持するのは困難であり、自己の専門以外の分野についての理解が十分では無い技術者が多くなっている。実務として情報システムの開発を担当する技術者は、対象とする業務分野あるいは個々の顧客の要求についての理解を深める事に忙しく、情報技術の急速な進歩に追従できないのが実情である。情報技術の進歩に関する概観を得るために商用雑誌や安易な解説書等を情報元にする事は、商業出版物の持つ選択の恣意性を考慮すると、参考とするには問題はないが参照されるべきものではない。少なくとも情報技術者間での議論において参照される資料が公的なものでないのは問題である。技術参照モデルに限らず FEAPMO では各参照モデルについての開発／更新を継続しており、公的な機関が公的なプロセスの中でこういった参照資料を提示することは重要である。

今後の課題

FEA/TRM は米国における電子政府化政策の一貫として開発されたものであり米国連邦政府の業務に基づいて導出されたものである。よって、FEA/TRM は情報技術一般という意味で電子カルテに流用できる部分があるが、日本の医療機関や医療情報システム産業の性質との整合性は検証されていない。そこで本研究において業務分析から導出されるエンタープライズ・アーキテクチャとFEAの違いを検討し、FEA/TRM を基準に電子カルテに適合した技術参照モデルを開発する必要がある。

Chapter�3.�情報技術選択の非技術的側面

Table of Contents

資材調達型の導入方式の問題

医療機関における情報システム部門の不在

エンタープライズ・アーキテクチャ＋医療情報技師＋ITアウトシーシング＝プロセスとしての電子カルテ導入

エンタープライズ・アーキテクチャ(再訪)
医療情報技師
ITアウトソーシング
情報技術選択との関係

情報技術の選択を行う上では、選択対象としての情報技術自体の分析／評価だけでなく、情報技術を取り巻く環境としての非技術的側面についても検討が必要である。非技術的側面とは、技術参照モデルで示される各種の情報技術自体及び情報技術の基盤となる情報工学、計算機科学や数学等の技術的側面とは対照を為す、情報技術及び情報システムが存在する為に必要な環境にかんする事項である。具体的には情報技術が活用される情報産業の社会的経済的な構造、情報システムを導入する組織の構造や性質、それらに関連する行政や法規等である。この様な非技術的側面を無視／軽視した情報技術の選択は学術的なものでしかなく、実際の情報システムの開発／導入を誤った方向に導きかねない。

例えば、ある優れた能力をもった開発チームが顧客の要請で最先端の情報技術に基づいて電子カルテを開発したとする。しかし、保守チームがその技術を理解できず、かつ、その技術に対応した各種のツールが用意されていなければ、運用時に保守を受けることはできない。そのような電子カルテは車輪の無い飛行機のようなものであり、一度稼働して問題がなければ良いが、保守ができないため最後には墜落するしかない。対策として、開発チーム自らが保守まで行うようにすると、開発チームは保守に忙殺されて新製品や新たな技術の開発ができなくなり、開発チームはその製品と運命を供にすることになる。これは優秀な技術者の潜在的な成果を失うという意味で開発企業にとってだけではなく社会全体としても損失となる。

情報技術にはそれ自身の特性としてのメリット／ディメリットがあるだけでなく、それを活用する環境においてのメリット／ディメリットもあるということである。情報技術の選択に際してはそれが活用される環境との関係について、具体的に考慮せねばならない。この章では電子カルテに関わる非技術的側面についての関心を喚起するため、医療機関における電子カルテの導入における各種の問題点について検討を行う。

資材調達型の導入方式の問題

既に多くの電子カルテやオーダー・エントリー・システムが医療機関に導入されているが、運用現場において少なからずクレームを聞く。この問題が情報システムの開発工程の質が低いことだけに起因するとは考えにくい。実際、日本の情報システム開発技術は世界的に高いレベルにあると評価されているのである。したがって開発工程以外にも何らかの原因があるのではないかと考えられる。

一般に情報システムの調達は、請負契約あるいは売買契約または両者の混合契約である製作物供給契約に基づく取り引きで行われていると見なされる。請負契約は厳密には、請負人が注文者から何らかの「仕事の完成」を請け負うものであって、完成された物の所有権がどちらにあるかは定めていない。もし、全ての材料が請負人が用意したのであれば、完成された物の所有権は請負人にある。実際に完成した物の注文者への引き渡しは売買と見なされる。請負契約であれ売買契約であれ、引き渡しの際に瑕疵(不具合、バグ、故障)が有れば注文者は補償を求める事ができる。また、引き渡し後の一定期間(一般的には１年)も同様に瑕疵についての補償を求められる。

瑕疵の有無の判断の基準となるのは、契約時に何らかの形で行われた合意(仕様書や検査証など)である。この合意を満たしているのであれば、完成された物が注文者の意図に沿っていなかったり、何らかの問題が有ったとしても瑕疵とは認定されない。実際、民法６３６条は請負契約において注文者の指図に原因があって瑕疵が生じた場合は請負人は担保責任を負わないことが書かれている。ただし、請負人が専門家として注文者の指図の不適当なことを知っていてこれを注文者に告げなかった場合は請負人が担保責任を負うとも書かれている。しかし、医療情報システムにおいては医療の特殊性／専門性が極めて高いため、情報技術の専門家に対して仕様書の医療の面から見た不適当さの指摘を求めるには限界があると考えざるを得ない。

売買契約として購入する場合においても、販売者が提示する仕様書に基づいて購入するか否かを決めるわけであり、購入者が自らの目的を達成可能かどうか判断するのは購入者の責任である。メーカの書いた仕様書を理解し判断するのは、自らの要求を仕様書に記述する以上に高度の知識と洞察力が必要であろう。

仮に、非常に複雑な情報システムである電子カルテの仕様を厳密に記述するとなれば、それこそ百科辞典か長編小説になってしまうだろう。一方、曖昧な仕様書で無理やりに合意する事で、注文者が納入後に気づいた不満な点を瑕疵と認定し、それへの補償であるとしてシステムの修正を要求するというやりかたも事実上は不可能ではない。この場合は「○�業務支援機能を有すること」と仕様書に一筆入っていればよいのである。○�機能支援機能が厳密に定義されていないのであれば、○�業務のを行う上での不満の解消は全て瑕疵であると主張することができる。このやりかたは、仮に請負人が不服を申立てて裁判となれば、機能の認定や仕様書の合意の過程等が論点となるが、簡単に決着がつくことはないだろう。実際、このような裁判が行われることは稀である。

実際に行われている電子カルテやオーダー・エントリー・システムの調達では個々の機能が一筆で記述された仕様書が取り交わされていると考えられる。一筆型の仕様書に基づいた導入は電子カルテメーカ、医療機関の双方に問題をもたらす。電子カルテメーカは、納入後の(瑕疵の補修としての)改造要求に応える為の費用をあらかじめの納入価格に保険として上乗せしておかなければならない。このため、電子カルテの価格は高騰することになる。一方、医療機関側は納入された時点では、要求を完全に満たすものを手にする事ができない。その上、稼働後のシステムの改造は一般的にはシステムを複雑かつ不安定なものにしてしまう。高い電子カルテを導入したにも関わらず、思った通りの動きはしないしバグだらけだ、という声の原因ではないかと考えられる。

医療機関における情報システム部門の不在

有る程度の規模の企業には専任スタッフによる情報システム部門があり、電子カルテやオーダー・エントリー・システムのような組織の根幹業務を支援する大規模な情報システムの導入において、開発やプロジェクトの指揮／管理、そして導入後の保守を行うのが普通である。しかし、大学病院や大規模な医療法人を除けば医療機関に情報システム部門は存在しない。また、大学病院の医療情報部にしても研究組織という側面もあり純粋に情報システム部門とは言い切れない。

通常、情報システム部門を持たない医療機関における電子カルテやオーダー・エントリー・システムを導入する場合、診療科や診療部門から担当者を集めワーキング・グループや委員会等の形で１年から３年程度の期間をかけて仕様の検討が行われる。

このような体制では、電子カルテの要件について科や部門からの個別の要求はあがるが組織全体としての戦略的な視点で仕様をまとめることは困難である。また特に医師などは頻繁に医療機関を異動するため、長期的な戦略に責任を負うことができない。例えばある部門の責任者が「部門体制の編成が間に合わないので今回は部分的な電子化にとどめ、全面的なシステム化は次回の調達に見送る」といったような戦略的な判断をすることができない。

前節の仕様書についての議論からもわかるように、情報技術に関する知識だけでなく企画力や交渉力をもった専任スタッフをもたない医療機関にとって、電子カルテの導入はまさにギャンブルである。

エンタープライズ・アーキテクチャ＋医療情報技師＋ITアウトシーシング＝プロセスとしての電子カルテ導入

現状の、資材調達型の導入方式と医療機関の情報システム部門不在という問題が残される限り、どんなに優れた仕様や実装の電子カルテが開発されたとしても、導入の過程は難航し導入後も十分な効果を引き出すのは困難であると考えられる。なぜなら、これらは非技術的側面の問題であって、技術的側面である情報技術はこれらを解決することができない。

このの問題を解決する一つの方法は、電子カルテの導入を一過性の「イベント」としてとらえるのではなく「プロセス(工程、過程)」ととらえる事である。プロセスには、それを導く枠組が必要であり、また、プロセスを実行する人的資源が継続的に必要である。そこで、枠組としてエンタープライズ・アーキテクチャ、人的資源として医療情報技師とITアウトソーシングを活用することを提案する。

エンタープライズ・アーキテクチャ(再訪)

エンタープライズ・アーキテクチャは資材調達型の情報システム導入の弊害に対応することが出来ることから、米国連邦政府の電子政府化政策における枠組の核となったものであり、医療機関にとっても有効と考えられる。ただし、エンタープライズ・アーキテクチャを行うためにはかなりの人的資源が必要となる。その一つの例が米国連邦政府エンタープライズ・アーキテクチャの中で配布されているガイドライン [5]に示されている。少なくとも情報責任者(Cheif Information Officer, CIO)が必要であり、その他にも業務の分析やプランニングをするアーキテクトが必要となる。通常、医療機関は医師やコメディカル等の医療従事者と事務職員と施設管理職員だけで構成され、常勤の情報管理職員が置かれることはまずない。電子カルテやオーダー・エントリー・システム等の大規模な情報システムの導入費用を考えると、情報システムを効果的に導入／運用ができるのであれば、そういった情報管理職員の人件費は決して無駄では無いと考えられる。

医療情報技師

今まで、医療機関に情報技術や情報システムあるいは情報の管理を担当する専任かつ常勤の職員が置かれなかった理由は、大規模な情報システムの導入が一般的ではなかったためそのようなスタッフの必要性が無いと考えられていたこともあるが、それだけでなく一体どのようなスキルをもった人間を雇用すれば良いのか基準が無かったことも考えられる。とりわけ、医療機関は資格を持った人間によって構成されている非常に特異な組織であり、情報技術者という資格の無い専門家を雇用するという考え方自体が馴染まない。

日本医療情報学会では平成１５年より医療情報技師の育成事業を始めた。これは厚生労働省による「保健医療分野の情報化に向けてのグランドデザイン」を達成する為には必要な技術者を育成する事が急務とされたからである。医療情報技師とは「保健医療福祉専門職の一員として，医療の特質をふまえ，最適な情報処理技術にもとづき，医療情報を安全かつ有効に活用・提供することができる知識・技術および資質を有する者」であり、そのような専門家を能力認定しようとういう制度である。「技師」とはついているが臨床放射線技師や臨床検査技師のような「資格」ではないが、雇用の際の一つの明確な基準とすることができる。

医療情報技師の育成は始まったばかりの事業であるため、講習や検定の内容はこれから更に検討が加えられていくものであるが、エンタープライズ・アーキテクチャを行うために必要な能力として企画力や交渉力の養成が加えられることを期待する。医療情報技師はコンピュータオタクであってはならない。

ITアウトソーシング

エンタープライズ・アーキテクチャは継続的に行うものではあるが、電子カルテ導入時のような大人数のスタッフが常時必要なわけではない。したがって何人ものスタッフを抱える情報システム部門を維持する必要は無くアウトソーシングを行うべきである。

アウトソーシングは業務の外注や要員の派遣とは異なったものである。業務の外注は請負契約((民法632条)であり仕事の結果について代価を支払うものであって、作業の過程について指揮することはできない。一方、要員の派遣については作業の過程について指揮する権利(義務)が得られるが結果については保証されない。どちらも依頼する側に大きなリスクがある。アウトソーシングは言うならばこれらの中間的なものであり依頼側が一方的にリスクを負うことが無く、受注側もスケールメリットや専門性による利益が得られるように留意した形態での業務委託の契約をするものである。業務の外注という見地からみれば、小さな単位の仕事(サービス)を継続的反復的に外注している状態であり、大きな単位での請負にある仕様書のリスクが負わなくて良い。要員の派遣という見地からみると、指揮の責任を負わなくて良いが、細かい指示をすることができる。

医療機関では小数の医療情報技師による情報システム部門を CIO として機能させ、高度な情報技術を要する分析や設計などの業務、或は、情報システムの保守などをアウトソーシングするのが効率的と考えられる。アウトソーシング・ベンダは情報システムの納入業者とは中立的であることが望ましい。

情報技術選択との関係

エンタープライズ・アーキテクチャにおける情報技術選択は戦術的ではなく戦略的なものになる。

従来型の情報システムの開発／導入では「情報システムのこの機能を実現するにはこういう情報技術が必要である」が選択の基準であり短期的かつ局所的(即ち戦術的)な判断であった。したがって、個々の情報システム開発時の判断によって情報技術が選択され、同じ組織内の情報システム間で互換性や接続性の問題を引き起こしていた。しかし、エンタープライズ・アーキテクチャでは情報技術は組織の資産と見なされるため長期的かつ組織横断的(即ち戦略的)な判断により選択され、個々の情報システムの要求によって左右されるものではない。

医療機関における情報技術の選択は、外来重視の経営か入院患者重視の経営か、特定疾患専門か総合診療、検査や給食、医療事務等の外注化を進めるか否かなどの病院運営の方針から導き出されるべきであって、システム開発に用いるツールや開発者の判断によってなされるべきではない。今後の課題として、医療施設運営(経営)の各種の特性と情報技術との関係についての分析が必要となる。これはまさに医療機関におけるエンタープライズ・アーキテクチャのの枠組と各種参照モデルを開発する作業である。

Chapter�4.�まとめ

情報技術選択について、選択のもととなる分類のモデルについて検討を行った。また、医療機関における情報システムの導入の問題について検討を行った。この二つ直接的には関連の無い事項の考察において、どちらもエンタープライズ・アーキテクチャがキーとなることが示された。エンタープライズ・アーキテクチャは情報技術技術者だけでなく医療機関の運営を改善していく上で重要と考えられる。エンタープライズ・アーキテクチャはまだ新しい考え方であり今後の研究を成果が期待される。特に医療分野への適用についての研究が進められることが期待される。

Bibliography

[1] John A Zachman. A Framework for Information Systems Architecuter. IBM Systems Journal. VOL. 26. NO. 3. 276-286. 1987.

[2] John F Sowa and John A Zachman. Extending and formalizing the framework for information systems architecture. IBM Systems Journal. VOL. 31. NO. 3. 590-616. 1992.

[3] CIO Council. Federal Enterprise Architecture Framework Version 1.1. September 1999. http://www.cio.gov/archive/fedarch1.pdf

[4] Federal Enterprise Architecture Program Management Office. The Technical Reference Model (TRM) Version 1.1. August 2003. http://www.feapmo.gov/resources/fea_trm_release_document_rev_1.1.pdf

[5] CIO Council. A Practical Guide to Federal Enterprise Architecture Version 1.0. February 2001. http://www.cio.gov/archive/bpeaguide.pdf

情報技術選択における技術参照モデルと非技術的側面

高田斑平成１５年度報告書 ドラフト

Chapter�1.�概要

Chapter�2.�情報技術選択と技術参照モデル

選択と分類

分類＝モデル

エンタープライズ・アーキテクチャと技術参照モデル

Zachman Framework

エンタープライズ・アーキテクチャ

Federal Enterprise Architecture (FEA)

Technical Reference Model (TRM)

今後の課題

Chapter�3.�情報技術選択の非技術的側面

資材調達型の導入方式の問題

医療機関における情報システム部門の不在

エンタープライズ・アーキテクチャ＋医療情報技師＋ITアウトシーシング＝プロセスとしての電子カルテ導入

エンタープライズ・アーキテクチャ(再訪)

医療情報技師

ITアウトソーシング

情報技術選択との関係

Chapter�4.�まとめ

Bibliography

高田斑平成１５年度報告書ドラフト