3.8 相互運用性とオープン標準

概要と動機

相互運用性とは、二つ以上のシステムが、互いの内部の仕組みを知らなくても、情報を交換し、交換された情報を使える能力です。オープン標準とは、公開されており、透明でコンセンサスに基づくプロセスを通じて開発され保守され、実装が無料(または公正、合理的、かつ非差別的)であるため、単一のベンダーの許可なしに、誰でも準拠するシステムを築ける仕様です。相互運用性のための設計とは、特注の統合、つまりちょうど二つのシステムをつなぎ、どちらかが変わるたびに作り直さなければならない、一回限りの特注のコネクタではなく、これらの共有された公開仕様を通じて接続するシステムを築くことを意味します。

大きな組織にとって、相互運用性は気の利いたものではありません。それは他のすべてが動く基盤です。企業は会社を買収し、ベンダーを入れ替え、数十の社内およびサードパーティのシステムをつなぎ合わせ、オープン標準は、新しいコンポーネントが書き直しなしにはまるようにするものです。政府にとって、賭け金はさらに高くなります。公共サービスは、多くの機関、政府の階層、民間の供給者にわたって提供され、全体の資産を管理する単一の主体はありません。給付を申請する市民は、異なる部門が所有する本人確認、税、医療、福祉のシステムに触れるかもしれません。それらのシステムは相互運用しなければならず、さもなければサービスは失敗します。公的機関はまた、何年もで測られる調達のサイクルで供給者を変えるので、単一のベンダーの独自のインターフェースへのどんな依存も、長く高価な罠になります。

繰り返される失敗モードは、相互運用性の反対、独自仕様によるロックインです。組織のデータとプロセスが、一つのベンダーの標準でない形式やインターフェースと絡み合い、切り替え、統合、あるいは後でデータを読むことさえ、法外にコストがかかるようになります。オープン標準が主な防御です。本章は、システムが相互運用しなければならない水準、それを可能にする標準、そしてそのためにどう設計し、調達し、認証するかを扱います。APIとインターフェース設計(2.3章)、分散システム(3.3章)、データ戦略とガバナンス(7.1章)、調達とオープンソース(10.3章)、コンプライアンスとガバナンス(4.6章)に密接につながります。

主要原則

相互運用性は設計に組み込まれるものであり、後付けではない。 構築の前に標準を決めてください。後付けは、インターフェースの書き直しとデータの移行を意味するからです。
特注の統合より、オープン標準を好む。 準拠するインターフェースは現在と将来のすべてのパートナーに仕え、特注のコネクタはちょうど一つにしか仕えません。
相互運用性には水準がある。 バイトを回線の向こうに届ける(技術的)ことは、二つの側がバイトの意味について食い違っているなら(意味的)、無価値です。
意味は共有された語彙に宿る。 識別子、コード体系、用語集こそが、交換されたデータを、単に送信可能なだけでなく、使えるものにします。
標準は、準拠して初めて本物である。 準拠テストのない「FHIRに対応」という主張は、相互運用性ではなく、宣伝です。
ロックインは総所有コストの決定である。 今日の安い独自仕様の選択肢は、しばしば明日の閉じ込められた資産という高価なものです。
政府は必要性を倍増させる。 公共サービスは、誰も管理しない組織の境界にまたがるので、オープン標準はしばしば好みではなく義務づけです。

推奨事項

相互運用性の四つの水準すべてのために設計する

欧州相互運用性フレームワークと関連するモデルは四つの水準を記述しており、システムが本当に相互運用するには、そのすべてを満たさなければなりません。技術的相互運用性は配管です。システム間でバイトを動かすネットワーク、プロトコル、トランスポート(たとえばHTTPS)。構文的相互運用性は、構造と形式、メッセージの文法についての合意で、JSON(JavaScript Object Notation、軽量なテキストのデータ形式)やXML(拡張可能なマークアップ言語)のようなもの。意味的相互運用性は、意味についての合意です。genderとラベル付けされたフィールドやコード250.00が、両者にとって同じものを意味すること。組織的相互運用性は、プロセス、ガバナンス、役割、法的合意の整合です。誰が、誰に、どのデータ共有の合意のもとで、何の目的で、何を送ってよいか。ほとんどの統合プロジェクトは最初の二つの水準を成し遂げ、三つ目と四つ目で失敗します。意味的で組織的な相互運用性を、後付けではなく第一級の設計作業として扱ってください。

データ交換とAPIの層を標準化する

システムがインターフェースをどう記述し公開するかについて、広く実装されたオープン標準を採用します。ウェブAPI(アプリケーションプログラミングインターフェース、あるシステムが別のシステムを呼び出す定義された契約)には、OpenAPI仕様を使います。それはREST(表現状態転送)APIの、ベンダー中立で機械可読な記述で、インターフェースを文書化すると同時に、クライアントコード、サーバー、テスト、モックを生成します。ペイロードの形式には、遍在性と人間にとっての読みやすさからJSONを好み、エコシステムがすでにそれに標準化している所ではXMLを使います。サービス間の高性能で強く型付けされた通信が必要な所では、gRPC(リモートプロシージャコールのフレームワーク)と、それ自体がオープンな仕様である、コンパクトでスキーマ定義されたバイナリ形式のProtocol Buffers(Protobuf)を検討します。要点は特定の技術ではありません。契約が公開され、機械可読で、独立して実装できることです。インターフェース設計の深さは2.3章を参照してください。

ドメインの認められた標準を採用する

ほとんどの分野は、ドメイン固有の相互運用性の標準に収束しています。自分で発明するのではなく、それらを使います。医療は主要な例です。HL7(Health Level Seven、標準化団体とその古いメッセージング標準)は、新しい仕事ではほぼFHIR(Fast Healthcare Interoperability Resources)に取って代わられました。それは臨床の概念(患者、観察、投薬)を、JSONやXMLを使ってREST APIで交換されるウェブリソースとしてモデル化する、現代的な標準です。金融では、ISO 20022が、構造化され豊かに注釈された支払いと金融メッセージングのオープン標準で、今や世界中の決済システムに採用されています。地理空間データでは、OGC(Open Geospatial Consortium)が、地図とフィーチャーのサービスのためのWMSやWFSのような標準を公開しています。その他の例には、ビジネス文書のためのOASISとUBL、建設のためのIFC(BuildingSMART)があります。認められた標準を選ぶことは、準拠するツール、供給者、訓練された人員という、エコシステム全体を買います。

識別子、コード体系、オントロジーに意味を固定する

意味的相互運用性は、共有された語彙を必要とします。同じ現実世界のものが、どこでも同じ参照を持つよう、標準の識別子を使います(たとえばISOの国コード、法人のLEI、国の患者識別子)。自由なテキストの代わりに、公開されたコード体系と用語集(定義された意味を持つコード化された概念の管理されたリスト)を使います。臨床用語にはSNOMED CTとLOINC、診断にはICD(国際疾病分類)、テキストにはUnicode。概念間の関係が重要な所では、RDFとOWL(W3Cウェブオントロジー言語)のような標準で表現されたオントロジー(概念とそれらの関係の、形式的で機械可読なモデル)を使います。これらの語彙のガバナンスはデータガバナンスの責任です。7.1章を参照してください。

ポイントツーポイントの配線ではなく、標準に基づくパターンで統合する

統合の数を、組み合わせ的ではなく線形に保つアーキテクチャのパターンを好みます。N個のシステムがポイントツーポイントで配線されると、最大N×(N−1)/2個の特注のコネクタが必要になりえます。同じN個のシステムがそれぞれ共有の標準に準拠すれば、その標準のN個の実装だけで済みます。ゲートウェイ、公開されたAPIの契約、正規のデータモデルを使い、新しい参加者がすべての既存システムに対してではなく、標準に対して一度統合するようにします。これはロックインへの解毒剤でもあります。契約がオープンなので、ベンダーを、それにつながるすべての人々に触れずに置き換えられます。

準拠と認証を求める

標準は、実装が実際にそれに準拠するときにだけ価値を届けます。公開されたテストスイートと検証ツール(たとえばFHIRの検証ツールとTouchstoneのテスト、あるいはビルドパイプラインでのOpenAPIスキーマの検証)を使った準拠テスト(実装が仕様を満たしていることの自動チェック)を求めます。国の医療ITの認証制度のように、認証プログラム(独立した団体が準拠を証明する)がある所では、認証された製品を好み、契約で認証を求めます。標準からのずれが本番で表面化せずにビルドを失敗させるよう、準拠チェックを継続的インテグレーションに組み込みます。

トレードオフ: 長所と短所

アプローチ	長所	短所 / コスト
オープン標準	多くの供給者、ロックインなし、エコシステムのツール、将来のパートナーが安く統合できる	標準が広く複雑なことがある。ニッチな機能の採用が遅い。委員会のペースの進化
特注のポイントツーポイント統合	最初の接続が速い。ぴったり合う。前もっての学習が最小	コストが組み合わせ的に増える。脆い。変更のたびにやり直す。ロックインを生む
独自のベンダー形式/API	豊富な機能、ベンダーのサポート、一つのエコシステム内での素早い開始	ロックイン、切り替えコスト、後でデータを取り出しにくい、価格決定力がベンダーに移る
ドメイン標準(FHIR、ISO 20022)	共有された意味、訓練された労働力、規制に整合	学習曲線、レガシーデータの対応づけ、バージョンとプロファイル管理のオーバーヘッド

最上位のトレードオフは、短期的な便利さと長期的な選択肢の価値です。特注や独自仕様の統合は、最初の接続を立ち上げるのはほぼ常に速く、だから組織は一つずつ妥当な決定を重ねてロックインに流れていきます。オープン標準はコストを前倒しにし(仕様の学習、既存データの対応づけ、準拠テストの構築)、新しいパートナー、供給者、システムが書き直しなしに加わるたびにそれを返済します。長い寿命と多くの参加者を持つシステム、ほぼすべての企業と政府のプラットフォームにとって、標準に基づく道が決定的に勝ちます。本当に使い捨ての一対一のリンクなら、特注が合理的かもしれません。誤りは、長寿命のプラットフォームを、使い捨てのリンクであるかのように扱うことです。

チームで議論すべき問い

技術的な統合が依存する組織的相互運用性(データ共有の合意、同意モデル、プロセスの整合)を所有するのは誰ですか。 ほとんどのプロジェクトは技術的で構文的な水準を成し遂げて、組織的な水準で止まります。バイトは届き解析されますが、誰が、誰に、何の目的で、どの同意のもとで何を送ってよいかを統治する合意がありません。政府では、市民のデータは、それぞれがシステムを所有し異なる法的根拠に答える機関をまたぐので、完璧なFHIRインターフェースは、共有の合意と同意モデルが存在するまで無価値です。最も重要な境界をまたぐ交換を持ち込み、APIだけでなく、法的な文書と、それぞれの側の責任ある所有者を名指ししてください。その所有者が名指しされていなければ、統合はあらゆる技術的テストに合格しても、本番でブロックされます。これらの合意を、メッセージスキーマと同じ厳密さの設計成果物として扱います。
標準の独自拡張にどれだけ頼っていて、別の準拠する実装でもあなたと通信できますか。 標準には逃げ道があり、それを使いすぎることは、オープンのバッジをつけた事実上のロックインです。FHIRやISO 20022をうたいながら、独立したベンダーがあなたの方言と実際には相互運用できない。これは妥当なカスタマイズ一つずつ忍び込むので、大きな資産では意図して測定すべきです。本物のメッセージを持ち込み、その意味のどれだけが標準のフィールドに乗り、どれだけがカスタムの拡張に乗っているかを数えてください。カスタムの割合が高いほど、可搬性が弱く、既存のベンダーの価格決定力が強くなります。私的な拡張より、標準のルールの範囲内のプロファイル化と、ギャップを標準に還元することを好みます。オープンな道の要点全体は、ベンダーを、つながるすべての人々に触れずに置き換えられることで、拡張はそれを静かに浸食します。
各標準のどのバージョンとプロファイルを使っていて、資産全体でその選択を統治するのは誰ですか。 「標準に対応」は、バージョンとプロファイルの規律なしには無意味です。二つのシステムがどちらもFHIRやISO 20022を主張しても、異なるバージョンやプロファイルを実装していれば、通信に失敗しうるからです。多くの供給者と長い調達サイクルを持つ大きな組織では、バージョンは、統合が壊れるまで静かにずれていきます。すべてのインターフェース、その標準、バージョン、プロファイルの一覧を持ち込み、それらを揃えておき、アップグレードを計画する責任者を名指ししてください。バージョンとプロファイルをパイプラインの準拠テストに組み込み、ずれが本番で表面化せずにビルドを失敗させるようにします。このガバナンスがなければ、名目上準拠するシステムも相互運用できず、それこそがオープン標準が防ぐはずだった失敗です。
契約や供給者が「標準に対応」と言うとき、それを実際に証明する独立したテストは何で、どこで動きますか。 テストの裏付けのない準拠の主張は宣伝であり、最悪の場所、お金が動いてシステムが稼働した後の本番で失敗します。多くの供給者から買う大きな組織では、質問票のチェックボックスを受け入れたくなります。検証された準拠を主張することは、調達を遅くし、入札者のプールを狭めるからです。依存する各標準の公開された検証ツールやテストスイート(たとえばFHIRの検証ツールとTouchstone、あるいはOpenAPIスキーマの検証)、本物のメッセージのサンプルをそれに通した結果、受け入れと支払いをそれに合格することに結びつける契約の条項を持ち込んでください。相反する引力は、速度と証明です。認証された製品はコストが高く、オンボーディングに時間がかかるかもしれませんが、検証されていないものは、失敗を統合チームに転嫁します。国の医療ITや決済の認証制度が存在する政府や規制された設定では、契約で認証を求め、ずれがビルドを失敗させるよう検証ツールを継続的インテグレーションに組み込んでください。テストしたことのない主張は、監査や障害の最中に発見する負債だからです。
統合のうちいくつがまだポイントツーポイントで、そのままにしておく本当の組み合わせ的なコストは何ですか。 特注の一対一のコネクタは、最初のリンクとして構築するのが最速で、資産全体で所有するのが最も高価です。数がN×(N−1)/2に向かって増える一方、共有の標準はN個の実装で済むからです。大きな組織では、この乱立が、統合のマップが保守不能になり、システムの変更がすべて、十数個の脆いコネクタに波及するまで、妥当な決定一つずつで積み重なります。統合をポイントツーポイントと標準に基づくものに分類した一覧、直近の大きなシステム置き換えで触れられたコネクタの数、特注のリンクの保守に費やされたエンジニアリングの時間の見積りを持ち込んでください。緊張は、稼働中のポイントツーポイントの配線をゲートウェイや正規モデルの背後に移すことが、すぐの機能の見返りがない本物の仕事で、誰かが保持コストを定量化しない限りロードマップに負けることです。何十年も生き、参加者を絶えず加える企業と政府のプラットフォームにとって、ポイントツーポイントの道は遅い税です。統合アーキテクチャの所有者と、新しい参加者を、すべての既存システムに対してではなく、標準を通して流す計画を名指ししてください。
公開されたコード体系や用語集が運ぶべき意味を、自由なテキストで伝えているのはどこで、それらの語彙を統治するのは誰ですか。 意味的相互運用性は、ほとんどの統合が静かに失敗する場所です。バイトは届き解析されますが、制約のない文字列として保存された診断、通貨、国は、送り手にとって一つのことを、受け手にとって微妙に異なることを意味します。大きな組織にとって、そのコストは、レポート、分析、規制当局が、同じ概念が三つのシステムにわたって三通りにコード化されていたことを露わにするまで、見えません。現在自由なテキストとして保持されているフィールド、それらを置き換えられる標準の識別子とコード体系(臨床データにはSNOMED CTとLOINC、国と通貨にはISOコード、法人にはLEI)、自由なテキストが隠しているエラー率や照合の労力の例を持ち込んでください。相反する考慮は、レガシーデータの管理された語彙への対応づけは骨が折れ、決してデモされないので、トランスポート層に比べて慢性的に資金不足になることです。市民のレコードが多くの独立したシステムから組み立てられ、一致しないコードが給付を拒否したり医療記録を壊したりしうる政府では、語彙のガバナンスを、各チームに任される実装の詳細ではなく、名前のあるデータガバナンスの責任(7.1章)として扱ってください。

セクター別の視点

スタートアップ。 速度が勝ち、オープン標準は、小さなチームが多くのコネクタを築かずに多くの顧客に届く方法です。すべてのパートナーがすでにサポートする形式を話してください(サインインにOAuth、スケジューリングにiCalendar、イベントにウェブフック、OpenAPIの契約上のJSON)。一つの統合が何千もの顧客に届き、ベンダーの入れ替えは一つのアダプターに触れるだけです。自前の形式を発明したり、各顧客のスタックを手で配線したりするのは避けてください。それは、人員を配置できない将来の保守です。標準の道は、前もって少しコストがかかり、まだ予測できない市場で切り替えを安く保ちます。

小規模事業者。 統合の専門家はおらず予算も厳しいので、相互運用性を構築のプロジェクトではなく、買う決定として扱ってください。分野のオープン標準をすでに話し、文書化されたAPIを公開するツールを好み、供給者を変えてもデータが可搬であるようにします。署名する前に、見込みのベンダーに、データをどう、どの形式で取り出せるかを尋ねてください。今日の安い独自仕様の選択肢は、明日の閉じ込められた資産だからです。自分で準拠テストを実行することはまれなので、認証された、あるいは広く相互運用する製品に頼ります。

大企業。 課題は、多くのチーム、供給者、長い調達サイクルにわたる相互運用性の統治です。ドメインの標準(FHIR、ISO 20022、OGC)と公開されたOpenAPIの契約を義務づけ、それから名目上準拠するシステムがずれないよう、バージョンとプロファイルと責任ある所有者を伴うすべてのインターフェースの一覧を保ちます。新しい参加者を、ポイントツーポイントの配線ではなく、ゲートウェイと正規モデルを通して流し、準拠の検証を継続的インテグレーションに組み込み、トラフィックのどれだけが標準のフィールドに乗り、どれだけが独自の拡張に乗っているかを測定します。ロックインと可搬性を、偶然ではなく、意図した総所有コストの立場として管理します。

政府。 公共サービスが単一の主体が管理しない機関にまたがり、供給者が複数年のサイクルで変わるので、オープン標準はしばしば義務づけです。すべての契約で準拠テストと、制度がある所では国の認証を求め、去るベンダーが公衆のデータを人質に取れないよう、データの可搬性を要求します。市民のレコードが部門間で同じ意味を持つよう、国の識別子と公開された用語集に意味を固定し、組織的相互運用性は、名前のある責任者を伴う明示的なデータ共有の合意と同意モデルで扱います。透明性と公的な財布はどちらも、どんな独自仕様の便利さよりも、オープンで独立して実装できる道を支持します。

事例

スタートアップ。 チーム生産性のアプリを構築する小さなスタートアップは、特注のコネクタではなく、オープン標準を通じて顧客の既存のツールにつなぎます。サインインにOAuth、スケジューリングにiCalendar、イベントにウェブフック。すべてのカレンダーと本人確認プロバイダーがすでにサポートする形式を話すので、一つの統合が一つではなく何千もの顧客に届き、後で決済やメールのベンダーを入れ替えても、一つのアダプターに触れるだけです。各顧客のスタックへの特注のリンクを手で作っていたら、新しいロゴごとに、書いて保守すべきコネクタがもう一つ増えたはずです。

大企業。 多国籍の銀行が、国境を越える決済を、レガシーの独自のメッセージ形式からISO 20022への移行でモダナイズします。標準は自由なテキストではなく、構造化され豊かに注釈されたデータ(支払人、受取人、目的、規制のフィールド)を運ぶので、不正スクリーニング、照合、報告の下流のシステムは、十数個の特注のパーサーではなく、一つの正規の形式を消費します。後に銀行が決済ゲートウェイのベンダーを入れ替えるとき、新しい供給者はすでにISO 20022を話すので、切り替えはゲートウェイに触れるだけで、背後の百のシステムには触れません。オープン標準は、ベンダーの移行を、数年にわたる再構築から、封じ込められた置き換えに変えました。

政府。 国の医療サービスは、二十年にわたって異なる供給者が作った、病院、診療所、検査機関、患者向けアプリが、レコードを安全に共有する必要があります。データ交換にFHIRを義務づけます。各システムは、患者、観察、投薬のデータを、REST API上のFHIRリソースとして公開し、コードがどこでも同じ意味を持つよう、標準の識別子(国の患者ID)と臨床の用語集(状態にSNOMED CT、検査結果にLOINC)を使います。供給者は接続する前に、FHIRの準拠検証に合格し、国の医療ITの認証を保持しなければなりません。新しい診療所のシステムは、すべての既存システムへの特注のリンクを築く代わりに、FHIR標準に対して一度統合し、市民は多くの独立したシステムから組み立てられた統一されたレコードを見られます。組織的相互運用性は、誰が何に、なぜアクセスしてよいかを統治するデータ共有の合意で扱われ、コンプライアンスの義務(4.6章)を満たします。

ビジネスケース: 動機、ROI、TCO

オープン標準の財務上の論拠は、最初の統合の定価ではなく、システムの寿命にわたる総所有コスト(TCO)についての論拠です。特注の統合のコストは接続の数に比例して増え、変更のたびに再び払われます。標準に基づく統合のコストは、参加者ごとに一度払われ、資産全体にわたって償却されます。投資収益(ROI)は、統合の労働の減少、新しいパートナーと供給者のより速いオンボーディング、ベンダーが期待に応えないときのより低い切り替えコスト、そしてどの競合も入札できないために唯一の供給者が価格を上げる、典型的なロックインの税の回避として現れます。

リーダーシップには、選択肢の価値と競争を軸に論拠を示してください。オープン標準は調達を競争的に保ちます(10.3章)。インターフェースが公開され準拠テストされていれば、複数のベンダーが対等な条件で入札でき、続く契約を通じて価格を下げ、質を上げます。また、将来のリスクも下げます。規制の変更、合併、モダナイゼーションのプログラムは、データとインターフェースが可搬なら、すべてより安くなるからです。標準を無視する最大の隠れたコストは、いずれ来る強制された移行です。元のベンダーがいなくなったり協力的でなかったりする状況で、事後に独自の形式からデータを取り出すことは、標準に基づく設計が前もってかかったであろうコストの何倍にもなるのが普通です。政府はこれをますます認識しており、数十年にわたってロックインから公的な財布を守るために、まさにオープン標準を義務づけています。

アンチパターンと落とし穴

技術的相互運用性が仕事全体と取り違えられる。 メッセージは届き解析されるが、双方がフィールドの意味について食い違い、データが静かに間違っていること。
名ばかりの「標準に基づく」。 製品が標準に対応していると主張するが、準拠テストに合格したことがなく、実際には異なること。
コード体系があるのに自由なテキスト。 診断、通貨、国を制約のない文字列として保存し、意味的相互運用性を破壊すること。
標準を飲み込む独自の拡張。 標準の逃げ道を重く使いすぎて、他の実装が相互運用できなくなること。オープンのバッジをつけた事実上のロックインです。
ポイントツーポイントの乱立。 統合のマップが保守不能な組み合わせの混乱になるまで、毎回もう一つの特注のコネクタを加えること。
バージョンとプロファイルの混乱。 標準のどのバージョンやプロファイルが使われているかのガバナンスがなく、名目上準拠するシステムも通信できないこと。
組織的相互運用性の無視。 データ共有の合意、同意モデル、プロセスの整合が存在しないため、完璧な技術的交換がブロックされること。
自前の標準を作る。 成熟して採用されたドメインの標準がすでにあるのに、特注の形式を発明し、その保守を永遠に引き継ぐこと。

成熟度モデル

レベル1: 開始。 統合は場当たり的でポイントツーポイントです。形式は独自仕様か文書化されておらず、意味は自由なテキストと属人的な知識で伝えられます。どのシステムやベンダーの置き換えも大きなプロジェクトです。ロックインは蔓延していて、大部分は認識されていません。
レベル2: 発展。 JSONやXMLのような共通の形式が現れ、一部のAPIは文書化されていますが、実践はチームごとに異なります。相互運用性はまだ大半が構文的で、意味的な合意は一貫せずプロジェクトごとです。標準は反応的に選ばれ、準拠は主張されるがテストされません。
レベル3: 標準化。 オープンなデータ交換の標準(OpenAPIと、FHIRやISO 20022のような関連するドメインの標準)が文書化され、組織全体で義務づけられています。共有の識別子、コード体系、用語集が意味的相互運用性を提供します。準拠テストはデリバリーパイプラインの一部で、統合はポイントツーポイントの配線ではなく、標準に基づくパターンに従います。
レベル4: 管理。 相互運用性がベースラインに対して測定され、制御されています。標準に基づく統合とポイントツーポイントの統合の割合、標準のフィールドに乗るメッセージの意味と独自の拡張に乗るものの比率、パイプラインでの準拠テストの合格率、資産全体でのバージョンとプロファイルのずれ、新しい参加者をオンボードする統合のリードタイムと欠陥率が、追跡されレビューされます。バージョンとプロファイルは統治され、認証は供給者に求められ検証され、ロックインのリスクは感じられるのではなく定量化されます。インターフェースを採用、アップグレード、退役させる決定は、この証拠に基づいて行われます。
レベル5: オーケストレーション。 相互運用性は継続的に改善され、組織全体に統合されています。組織的相互運用性(合意、同意、プロセスの整合)は技術的な層と並んで体系的に扱われ、組織は依存する標準に貢献を還元し、可搬性は恒久的な設計上の制約です。資産は、標準が進化し参加者が加わったり去ったりするのに応じて適応し、インシデントではなく測定された証拠に基づいて、統合アーキテクチャと語彙のガバナンスを再均衡させます。

議論のためのアイデア

最も重要なデータ交換で、四つの水準(技術的、構文的、意味的、組織的)のどれが今日最も弱いですか。
主要なベンダーが更新時に価格を倍にしたら、切り替えにどれだけの時間とコストがかかり、何がそうさせていますか。
統合のうち、どれがポイントツーポイントで、それらを共有のオープン標準の背後に移すには何が必要ですか。
公開されたコード体系や用語集が置き換えられる自由なテキストをどこに保存していて、自由なテキストはどんなエラーを隠していますか。
契約の「標準に対応」は、独立した準拠または認証のテストへの合格を要求しますか。それとも単に主張されるだけですか。
どのオープン標準の義務づけ(国や分野の)がすでにあなたに適用され、それを実際に満たしていますか。それとも主張しているだけですか。

要点

相互運用性とは、交換された情報を、単に送信するだけでなく使うことを意味します。技術的、構文的、意味的、組織的の四つの水準すべてのために設計します。
ロックインと組み合わせ的なコストを生む、特注の統合や独自の形式より、オープンで公開され独立して実装できる標準を好みます。
APIとデータ交換の層(OpenAPI、JSON/XML、gRPC/Protobuf)を標準化し、ドメインの認められた標準(医療のFHIR、金融のISO 20022、地理空間のOGC)を採用します。
共有の識別子、コード体系、用語集、オントロジーに意味を固定します。意味的相互運用性は、ほとんどの統合が静かに失敗する場所です。
準拠テストと、利用できる所では認証を求めます。標準は、実装が実証的に準拠するときにだけ本物です。
選択を、システムの寿命にわたる総所有コストと選択肢の価値で判断します。長寿命で複数の当事者が関わるプラットフォーム(ほぼすべての企業と政府のシステム)では、オープン標準が勝ち、政府はますますそれを義務づけています。

参考文献とさらなる読み物

HL7 International, FHIR (Fast Healthcare Interoperability Resources) specification (hl7.org/fhir)
ISO 20022, Universal financial industry message scheme (iso20022.org)
OpenAPI Initiative, OpenAPI Specification (Linux Foundation)
Open Geospatial Consortium (OGC) standards (WMS, WFS, and successors)
European Commission, European Interoperability Framework (EIF) and the Interoperable Europe Act
UK Government, Open Standards Principles and the Technology Code of Practice (GOV.UK)
W3C, RDF, OWL (Web Ontology Language), and semantic-web standards
SNOMED International (SNOMED CT), Regenstrief Institute (LOINC), and WHO (ICD) terminologies
gRPC and Protocol Buffers specifications (Cloud Native Computing Foundation / open source)
NIST and IEEE literature on systems interoperability and conformance testing