Reference Enterprise Architecture Scope Statement

Practical Guide to SOA in Healthcare ii

This page intentionally left blank

Practical Guide to SOA in Healthcare vii

Executive Summary

要旨

Across the globe, healthcare organisations are increasingly making IT investments to improve their operations, efficiency, more effectively manage costs, and improve their operational capabilities. IT shops can be hampered in their efforts to evolve due to extensive existing investments in hardware, software, and medical devices that they must continue to support, while coming under increasing pressure to modernise systems. The need to change is pushed by technologies are constantly evolving. IT planning processes are also complicated by “industry recommended practices” that are hyped by the technology journals.

全世界的に、医療機関は、その経営、効率性を改善するために、より効果的にコスト管理を行うために、またその経営能力を改善するために、IT投資を増大させている．増大するシステム更新の圧力にもかかわらず、継続的にサポートしなければならないハードウェア、ソフトウェア及び医療機器への大量の既存投資のため、IT部門は発展のための努力が妨げられる可能性がある．絶え間なく発展する技術により、変化は常に必要である．

One such area receiving significant amounts of this hype is service-oriented architecture (SOA). In a nutshell, SOA provides an approach for business transformation based on dividing complex environments into well defined, formally specified functions based on the activities they perform (services). Each service has well defined responsibilities and authority. These services then work together in collaboration to support the workflow of the business, all within the context of governance and oversight that manages their coordination and performance. It is being touted as everything from “the next silver bullet” to a technology platform[1] to an enterprise change management strategy.

大量のこの誇大宣伝を受けている領域の一つがサービス指向アーキテクチャ（SOA）である．

一言で言えば、SOAは、複雑な環境を分割して、それが成す活動（サービス）に基づく、洗練され形式的に仕様化された機能群への業務変革方法を提供する．これらのサービスは、協力して、すべてそれらの協調と成果を管理する支配と監督の状況の下、業務のワークフローをサポートする．SOAは、技術基盤1の次世代の特効薬から組織管理変革戦略までのすべてのものであると宣伝されている．

SOA programmes involve cooperation and coordination among a wide variety of participants from across an organisation. Whether senior management sponsorship, business community ownership, program management governance, or project level execution and sustainment, SOA involves a broad variety of participants all of whom must actively engage to realise organisational success.

効果的なSOAプログラムは組織全体にわたる他職種の参加者の協力と協調を伴っている．上位管理職の支援、業務共同所有、プログラム管理の支配、あるいはプロジェクトレベルでの実行と持続のどれであろうと、SOAは、組織全体の成功を実現するために積極的に関わらなくてはならない広い範囲の参加者を含む．

Why SOA? Why Act Now?

なぜSOAか？なぜ今行動？

Among the most difficult challenges facing healthcare organisations making IT investments today comes from deciding whether to go “all-in” with any particular vendor, or whether to self-integrate components from multiple vendors. The appeal of the single-vendor solution is strong – no “finger-pointing”, out-of-the-box integration, [US-based] EHR certification via the Certification Commission for Healthcare IT (CCHIT), and so on. This is contrasted with seemingly increased risk and work involved in a multi-vendor situation and involving integration. The tradeoff is that a multi-vendor solution offers best-of-breed options, and a SOA promotes the easy integration and alignment across suppliers into a cohesive architecture.

今日IT投資を行っている医療機関が直面している非常に困難な仕事の一つに、特定のベンダーに一括して頼むか、あるいはマルチベンダーによる複数のコンポーネントを自分で組み立てるか、決定する仕事がある．単一ベンダーのソリューションの魅力は強い－「責任追及」が不要、直ちに稼動可能、医療IT認証委員会（CCHIT）保証付きの［米国製］EHR、などなど．これは、マルチベンダーの状況で組み立て行うことによる、リスクと作業の表面的な増加と対照的である．そのトレードオフは、マルチベンダーのソリューションは最善のオプションの組合せを提供するということである、そしてSOAは、容易な組み立てと、供給者の連携によるまとまりのあるアーキテクチャを促進する．

In a nutshell, there are a few fundamental truths to consider to get a clear picture of your return-on-investment (ROI):

端的に言うと、投資回収の明確なイメージを得るために考慮すべき基礎的な事実はほんの少ししかないということである：

Legacy systems comprise a significant investment. Legacy systems make up the core of any business’ portfolio. While some of these systems may require replacement that may not be true for the entire portfolio. In many cases, there is either too little benefit or too much cost in replacing these systems. As a result, legacy systems will continue to retain data that is too expensive or “dirty” to migrate.

レガシーシステムは多大な投資からなっている．レガシーシステムは任意の事業戦略の核を成している．これらのシステムのいくつかは、事業戦略全体に対して正しくなくなった部分の交換を必要とする可能性がある．

No single vendor is best-of-breed at everything. The reality is that heterogeneous environments are here to stay. Whether required by a clinical subspecialty or mandated by government authorities, integration needs with unexpected systems and platforms will always exist.

すべてのことに最善な単一ベンダーはない．異種混合環境が普及しているというのが現実である．臨床専門分野の要求、あるいは政府当局による命令に関わらず、予期しないシステムとプラットフォームの構築ニーズは常に存在する．

The need to exchange health information across organisational boundaries is growing. Information sharing is happening between healthcare institutions that was unforeseen only a few years ago (e.g., shared care delivery, public health reporting, chronic disease management, biosurveillence). The need to expose access to service capabilities is being increasingly driven by patient-directed and community-based care.

医療機関の境界を越えた医療情報交換のニーズは増大しつつある．二、三年前までは予想もしなかった医療機関間の情報共有が起こりつつある（共同医療提供、公衆衛生の報告、慢性病管理、バイオテロ監視、など）．患者指向の地域社会に基づく医療によって、サービス能力へのアクセスの顕在化ニーズが徐々に促進されつつある．

Clinical medicine, workflow, and regulatory environment are ever-changing. The rules are changing, faster all the time, placing demands on healthcare organisations to more quickly react and support the needs of an evolving landscape, fostering clinical quality and consistency.

臨床医療、ワークフロー、及び法的環境は常に変化している．規則は、常時加速度的に変化しており、医療の質と整合性の育成のため、より迅速な対応と、変化しつつある環境のニーズのサポートを医療機関に要求している．

SOA provides some unique abilities to more quickly react, adapt, and institute changes within an organisation and its IT landscape due to the modular structure of services and ability to alter interactions among those service components. SOA is a proven architectural approach that is mature in many other market sectors and has shown benefit it healthcare organisations as well. Ultimately, organisations that have elected to utilise SOA solutions have done so to improve their agility (ability to respond to changing requirements), to more effectively develop and deploy IT systems, and to improve business ownership, accountability, and consistency.

SOAはいくつかのユニークな能力を提供している．すなわち、サービスのモジュール構造と、それらのサービス部品間の相互作用を変化させる能力により、組織とそのIT環境内で、より迅速な対応、適応、及び変化を可能にする．SOAは、他の多くの市場部門で熟成している、また医療機関でも同様に利益のあることを示している、実績のあるアーキテクチャ手法である．結局、SOAソリューションを利用することを選択した組織は、そうすることによって機敏さ（変化する要求に応える能力）を改善し、ITシステムをより効果的に開発及び配備し、事業の所有権や説明責任、整合性を改善する．

Principal Findings

主要な知見

Although SOA is a relatively new approach within the healthcare sector, it is an established, proven, and reliable approach that has realised business benefit in other industries. SOA is an architectural style (as is client/server, hub-and-spoke, etc.) that may be realised in a number of implementation forms. That said, do not confuse SOA with web-services, which is technology platform. Just because something is implemented using web services does NOT make it a SOA.

SOAは医療分野では比較的新しい方法であるが、他の産業では事業的利益をもたらしいてる、確立され証明された信頼のおける方法である．SOAは、多くの実装形式で実現されている一つのアーキテクチャ的流儀である（クライアント／サーバ、ハブとスポークなどのように）．と言っても、SOAをウェブサービスと混同してはならない．後者は技術基盤である．ウェブサービスを利用して実装されているというだけで、それがSOAというわけではない．

SOA provides some unique abilities to more quickly react, adapt, and institute changes within an organisation and its IT landscape. SOA is a proven architectural approach that is mature in many other market sectors and has shown benefit it healthcare organisations as well.

SOAはいくつかのユニークな能力を提供している．すなわち、組織とそのIT環境内で、より迅速な対応、適応、及び変化を可能にする．SOAは、他の多くの市場部門で熟成している、また医療機関でも同様に利益のあることを示している、実績のあるアーキテクチャ手法である．

One challenge that few organisations realise in time is that SOA does not itself guarantee interoperability, nor do web services. Tooling in the marketplace has improved, resulting in improved ability for organisations to build new “stovepipe systems” that do not necessarily interoperate. Overall, SOA successes share several core tenets, summarized below:

現在のところ、SOAそれ自身は相互運用性を保証しない（ウェブサービスも同様）ということを理解している組織がほとんどないことは大きな問題である．市場に出ているツール類は改善されており、その結果、相互運用する必要性のない、新しい「煙突システム」を構築する組織の能力が改善された．全般的に、SOAの成功にはいくつかの教義が共通している．それらは以下のとおりである：

Ø Based in Enterprise Architecture, fostering IT alignment with business needs
ビジネス・ニーズと整合の取れたITを育成する、エンタープライズ・アーキテクチャにベースを置いている．

Ø Supported by the business community under the authority of an Executive Sponsor as SOA often alters business responsibilities and organisational boundaries. This includes authority and governance to manage the overall programme.
SOAはしばしば事業責任や組織境界を変更するので、経営幹部の出資責任者の監督の下、その業務集団によって支持されていること．これは、全体のプログラムを管理する権限及び統制を含む．

Ø Encompassing of legacy systems, breaking up what had been large, monolithic applications into service capabilities, and fostering their co-existence with current infrastructure and investments[2]
レガシーシステムを包含する．これまで大きな、また一体構造であったアプリケーションをサービス機能に分割し、現行の情報基盤と投資と共存可能なように育成する．2

Ø Fosters discrete components with well defined responsibilities and interfaces, establishing authoritative ownership within the business and IT landscape.
明確な責任とインタフェースのもと個別部品を育て、業務とIT景観に権威あるオーナーシップを確立する

Ø Orthogonal to existing systems view, where focus is on identifying shared need across systems and organisations (e.g. not 1:1 between SOA services and department systems)
複数システムないし複数組織にわたる共通利益の認識に焦点が合わされている、既存のシステムの見方と直行している．（例えば、SOAサービスと部門システムは１：１ではない）

The figure (right) illustrates a macro-view of a SOA. It depicts five overlapping boundaries, each of which represents a context within the business and architecture:

右図はSOAのマクロ的景観を描いたものである．五つの重畳した境界を示しており、それらはそれぞれビジネスとアーキテクチャの状況を表している．

Ø The Inter-organisational Boundary (outermost) represents inter-organisational considerations, such as policies, sharing agreements, and business partners.
組織間境界（最外側）は、例えば方針、共有契約やビジネス・パートナーなど、組織間で考慮すべきことを表している．

Ø The System Boundary represents the physical platforms on which software and systems run, including servers, networks, and so on.
システム境界は、サーバ、ネットワーク等を含む、その上でソフトウェアとシステムが走る物理的プラットフォームを表している．

Ø The Application Boundary represents the software running on those platforms, inclusive of applications and data.
アプリケーション境界は、それらのプラットフォーム上では走る、アプリケーションとデータを含むソフトウェアを表している．

Ø The Business Process / Orchestration Boundary manages the intersection between software and workflow, and would manage coordination among multiple software components that all must interact to satisfy business needs.
ビジネス・プロセス / 編成境界は、ソフトウェアとワークフローの共通部分を管理している．また、複数のソフトウェア部品－これらはすべてビジネス・ニーズを満足するために相互作用をしなくてはならない－間の協調を管理している．

Ø Finally, the Service Implementation Boundary depicts the implementations themselves, interacting across a service bus, and realising the architecture.
最後に、サービス実装境界は、サービス・バス間にわたって相互作用を行い、アーキテクチャを実現している実装そのものを表している

This diagram, more richly elaborated later in the document, forms the basis to demonstrate how a SOA can co-exist with legacy and commercial applications within an organisation.

あとでもっと詳しく述べるが、この図は、SOAが組織内でどのようにしてレガシーアプリケーションや商用アプリケーションと共存することが出来るかを示す基盤を形作っている．

Approaches to SOA

SOAへのアプローチ

There are many viable methods for approaching SOA implementations. Some organisations elect to follow a “top-down” method, functionally breaking-down the business processes to identify the common services needed across the organisation. Other organisations approach SOA more opportunistically, starting from one easily-identified service need and growing the architecture from there. Finally, SOA-enabling “legacy” applications is one way to further the useful life of existing IT investments while taking a step into the SOA world.

SOAの実装にいたる多くの実行可能な方法がある．いくつかの組織は、ビジネスプロセスを機能的にブレイクダウンして組織全体にわたる共通サービスを同定するという「トップダウン」手法を選択している．他の組織は、SOAについて、一つの容易に同定されるサービスニーズから始め、そこからアーキテクチャを育てるという、より日和見的な取り組み方をしている．結局、SOA化可能なレガシーアプリケーションは、SOA世界に足を踏み入れつつ既存のIT投資の耐用年数を延ばす一つの方法である．

There is no right or wrong approach, despite industry literature that may indicate otherwise. The right decision for your circumstance will likely depend on your own organisational culture, willingness to embrace change, planning and budgetary cycles, and existing investments. Throughout this document, we have centered the discussion around the “top down” approach as it is a bit more systematic and comprehensive than the alternatives. That said, a hybrid approach employing a top-down method coupled with opportunistic bottom-up instances that can grow organically is an approach many of the authors have used within our own organisations with success.

業界文献は別の言い方をしているかもしれないが、正しい方法も間違った方法もない．読者の状況に対する正しい意思決定は、読者自身の組織の文化や、変化、計画と予算サイクル及び既存の投資を受け入れる意思に、おそらく依存している．他の方法よりもシステム的であり包括的なので、我々は本文書全体にわたって「トップダウン」手法を議論の中心においた．とは言え、組織的に育成可能な日和見主義的なボトムアップ事例とトップダウン手法を合わせた混合手法も、多くの本文書の著者が自身の組織の中で成功を収めている手法である．

Health Industry SOA Standards

医療業界のSOA標準

In an effort to help promote alignment among SOA implementations, and to further interoperability among organisations as they seek to realise SOA-based architectures, the Healthcare Services Specification Project (HSSP) was formed. This effort is a joint collaboration among standards groups--specifically Health Level Seven (HL7) and the Object Management Group (OMG)—developing health industry SOA standards. The intent of HSSP is to produce standard services that define services’ responsibilities, behavior, and interfaces so that ubiquity can be achieved across implementations and vendor products. HSSP services align with the architectural diagram above, and have a role in assuring that SOA’s for healthcare organisations are interoperable and standards-based.

SOA実装間の調整推進の支援や、SOAを基礎とするアーキテクチャを実現しようとしている組織間で相互運用性を推進するため、医療サービス仕様プロジェクト（HSSP）が形成された．これは、医療業界SOA標準を開発しようとする標準化グループ（特にHL7とOMG）の共同事業である．HSSPの目的は、標準サービスを生成することである．この標準は、実装とベンダーの製品によりSOAが普及できるよう、サービスの責任、振る舞いとインタフェースを定義する．HSSPサービスは、上記に示したアーキテクチャ図式と整合性を取り、医療機関のSOAサービスが相互運用可能で標準ベースとなることを保証する役割がある．

Practical Guide to SOA in Healthcare vii

Practical Guide to SOA in Health Care

Executive Summary 要旨 i

Principal Findings 主要な知見 iii

1 Overview 概要 1

2 Document Scope 文書記述範囲 1

2.1 Document “Tour” and Structure 文書「一覧」と構造 3

2.2 How to use this document 本文書の利用法. 4

2.3 SOA-101 SOA-101 5

2.4 Healthcare SOA Standards and HSSP 医療SOA標準とHSSP 6

2.5 Healthcare-specific SOA Challenges 医療特有のSOAの課題 7

2.6 Core Principles 中核原理 9

3 Establishing a Healthcare SOA 医療SOAの確立 14

3.1 Business case for SOA SOAのビジネスケース 14

3.2 Introducing SampleHealth SampleHealthの導入 15

3.2.1 Step 1: Enterprise Architecture ステップ1：エンタープライズ・アーキテクチャ 15

3.2.2 Step 2: Define and Analyse As-Is State ステップ2：現状態の定義と分析 20

3.2.3 Step 3: Identify Candidate Services ステップ3：候補サービスの同定 21

3.2.4 Step 4: Define Future State ステップ4：未来の状態の定義 25

3.2.5 Step 5: Specify Architecture and Services ステップ5：アーキテクチャとサービスの仕様定義 31

3.2.6 Step 6: Build A Transition Plan ステップ6：移行計画の作成. 35

3.2.7 Step 7: Realise the SOA ステップ7：SOAの実現 38

Step 8: Deploy and Sustain ステップ8：配備と維持継続 42

3.3 Lessons-Learned 学んだ教訓 46

3.3.1 Design Principles 設計原則 48

3.3.2 Enabling Legacy レガシーも可能にすること 50

3.3.3 “Localising” to Your Organisation 読者の組織への「局所化」 53

4 Acronym List 頭字語リスト 55

5 Glossary 用語説明 55

6 Acknowledgements 謝辞 55

7 References 参照文献 57

Practical Guide to SOA in Healthcare

This page intentionally left blank

Practical Guide to SOA in Healthcare

1 Overview

1 概要

This document considers service-oriented Architecture (SOA) from the perspective of a healthcare organisation considering a major information technology (IT) investment, recognising the value of existing systems, and mindful of the importance to demonstrate return-on-investment. If you are asking yourself how SOA fits within your organisation, whether healthcare SOA is any different from other industries, or how to approach a SOA implementation, then this document is for you.

本文書は、大きな情報技術（IT）投資を検討しており、既存システムの価値を認識し、投資対効果を証明することの重要性に留意している医療機関の観点からサービス指向アーキテクチャ（SOA）について検討している．SOAが自分の組織内でいかに適合するか、医療SOAが他の分野のものと違いがあるか、あるいはSOAの実現にどのように取り組むかを問うているならば、本文書は読者の役に立つ．

Service-oriented architecture has received increasing interest and coverage from industry literature as the “next-best-thing” for organisations facing integration and modernisation challenges. Though these claims are clearly exaggerated, SOA has reached a maturity in the marketplace and is demonstrating business value in many market sectors.

サービス指向アーキテクチャは、統合化と近代化の課題に直面している組織のための「次善の策」として、業界誌からますますの興味と取材を受けている．これら業界誌の主張は明らかに大げさであるが、SOAは市場で熟成の域に達しており、多くの市場分野でビジネス価値を現しつつある．

Healthcare traditionally has been an IT laggard, making fewer investments than in comparable industries. That said, there has been tremendous interest in SOA within the health community, and it is increasingly garnering attention from all types of organisations, from governments, to healthcare providers to payers to vendors.

医療は伝統的にIT導入が遅れており、他の同程度の産業分野と比べて少ない投資しかされていない．とは言え、SOAは医療界で大きな注目を得ており、また政府から医療機関、支払い者、ベンダーまで、すべての種類の組織からますます注目を集めつつある．

This document speaks to a business community, IT leadership community, and an IT application architecture/enterprise architecture community, and is not intended to be a detailed technical manual. It provides higher-level guidance outlining an approach for being successful using SOA, calling out industry best-practices and key factors for consideration in SOA implementation.

本文書は、ビジネス社会、IT指導者の社会、及びITアプリケーション・アーキテクチャ/エンタープライズ・アーキテクチャ社会に話をするのが目的である．詳細な技術マニュアルとすることは考えていない．SOA利用による成功方法の概要を記述し、業界の成功事例とSOA実現で考慮すべき主要な要因を提供する高次元のガイドを提供する．

2 Document Scope

2 文書記述範囲

This document is being provided as a “jump-start” to help you and your organisation be more successful in your efforts to apply SOA. This document does not address every specialty or nuance that you are likely to face, instead focusing on the mainstream of how SOA may be used to address typical challenges faced in health care organisations and environments.

本文書は、読者と読者の所属組織がSOA適用に当たってより大きな成功を得られるよう支援するための活性剤として準備されている．本文書は、読者が出会う可能性のあるすべての特殊状況や微妙な差異については扱っていない．その代わりに、医療機関とのその環境が出会うであろう典型的な課題を取り組むためにSOAをいかに使うべきかという主要な話題に集中している．

This document has a few simple objectives:

本文書はいくつかの単純な目的を有している：

Ø To present, in plain English, the business case, context, and an approach for applying SOA into a healthcare organisation
ビジネスケース、背景およびSOAを医療機関に適用する手法を、平易な英語で提示すること

Ø To provide a basic approach to use SOA, distilling many methodologies and industry-best-practices into a simple, concise process.
多くの方法論や業界成功事例から抽出して単純簡潔な過程とした、SOA利用の基本的方法を提供すること

Ø To illustrate, by example, how healthcare industry SOA standards (such as HSSP standards) may be used within an organisation’s IT architecture.
医療分野のSOA標準（例えばHSSP標準）が、組織のITアーキテクチャ中でどのように利用されるか、例を持って描くこと

To address these matters, the community elected to produce this informative guide, providing contextual information and implementation guidance without expectation of compliance. In other words, feel free to use the advice in this document that you find useful, and toss the bits that are not. Caveat emptor. The following will help you determine if this guide is applicable to your needs.

これらの事柄を取り扱うために、このコミュニティは、法令遵守の期待なしに背景情報や実装ガイドを提供するこの情報ガイドを作成することを決定した．別の言葉で言えば、この文書の情報を自由に使ってよい、そうでないものも放り上げてよい．すなわち、買主危険負担、である．このガイドが読者のニーズに適用可能であれば、以下の項目は読者の意思決定に役立つだろう．

This Practitioner’s Guide is NOT…

この実践ガイドは以下ではない...

Ø ….a normative standard
....規範標準

Ø …detailed or granular enough to be an implementation guide on its own
...これ自身で実装ガイドとして十分な詳細度や粒度を有する

Ø …a how-to guide for constructing profiles that are aligned to specific frameworks, data models, documents etc
...特定の枠組み、データモデル、文書その他と整合性を有する下位標準を作成する入門ガイド

Ø …an architecture to build a specific, given service (e.g., product architecture)
...特定の、所与のサービス（例、製品アーキテクチャ）を構築するアーキテクチャ

Ø …a methodology to support standards development
...標準開発を支援する方法論

The stark reality is that architectures are best realised when business-driven, and the key design principles and environmental factors affect how that architecture is manifested. It is for this reason that this document is a “Practical Guide” and not a formal Healthcare SOA Standard. By creating the document in this light, we hope to convey many of the best-practices, lessons-learned, and community experiences to you in a coherent, cohesive example that you can adapt to your situation.