旧 2. 実装手法の詳細（§2.0）

実装サポート情報（§2.0.1）

この章は、FHIR を業務システムで使用する際の、システム実装者向けのコンテンツです。

すべてのスキーマを含む ZIP ファイル（サポートスキーマ、リソーススキーマ、個別＆合成スキーマおよびスキーマトロンを含む）
検証キット FHIR 検証ツール（Java *.jar ファイル）とその動作に必要なすべてのファイル（Saxon の対応バージョンを含む）
翻訳ファイル FHIR の共通名称やメッセージの多言語対応ファイル（このファイルへの追加方法は wiki を参照）
リソースプロファイルをひとつにまとめたフィードリソースやコンフォーマンス宣言のプロファイルを記述する出発点として有用なリソースプロファイル群
すべてのリソースのサンプルを含む ZIP ファイル（同じ内容の JSON 版）

残件：RDF および OWL 記述、eCore 定義、ADL 版、その他要望のある情報の追加

サンプル実装（§2.0.1.1）

以下のサンプル実装は、システム実装者の便宜を図るために提供されています。これらのサンプルを業務システムに使用しても構いませんが、その使用に関して HL7 やサンプルの提供者は何らの責任を負うものではありません。ここに上げたサンプル実装はすべて、OSI 承認済みの標準 BSD ライセンス（三条項BSDライセンス）の下で提供されます。

ここでのサンプル実装は、リソースのコンテンツをネイティブ形式で表現し、それらを XML または JSON 形式でパーシングおよびシリアライジングを行うコードに限定されます。それに加えて、リソース定義の生成、使用および解釈を助ける実装もいくつか含まれます。これらのサンプル実装を用いたものも含め、本格的なオープンソースの FHIR の実装システムについては HL7 Wiki にリストがあります。

コンフォーマントとなるために、ここに上げたサンプル実装を使う必要はありません。スキーマからコードを生成するといった、他の手法を使うこともできます。

Delphi：リソース定義および XML と JSON のパーサー。 D5+。残件：未公開のコードへの依存部分の削除。
Java：リソース定義とパーサー（および残件多数）。Java によるサンプル実装は XmlPull (http://www.xmlpull.org/)、Java JSON ライブラリ (http://json.org) および Apache Commons Codec ライブラリ (http://commons.apache.org/codec/) に依ります。
C#：リソース定義（および残件多数）。
ECore：OClin ECore テキスト形式での正規オブジェクト定義（開発中）

サービス指向アーキテクチャでのリソースの使用（§2.0.2）

FHIR のリソースは、シンプルな HTTP 上での RESTful による実装を念頭において設計されていますが、実装に利用可能なフレームワークは、それに限定されません。この仕様では他にも、FHIR リソースの直接的なメッセージ交換形式での実装フレームワークや、ドキュメント形式での実装フレームワークを定義しています。

あるいは、以上述べたいずれの手法も使わなくてもかまいません。コンテキストに応じた利用可能な手法ならなんでも、リソースを交換したり保存したりすることができます。FHIR のリソースまたはバンドルのよくある利用法は、サービスインターフェースのパラメータとしてです。FHIR はそれ自身では、なんらの特定のサービスインターフェースを定義していません。その代わりに、他の標準や実装にて FHIR のリソースを用いるための独自のサービスインターフェースやアーキテクチャを定義したり、ひとつのやり方として FHIR RESTful 仕様の提供するリポジトリを介した交換手法の上に独自追加の機能を実装することもできます。使用されるリソースがこの仕様にコンフォーマントであり、リソースを生成したり読み込んだりするアプリケーションに関するルールに従う限り、実装システムは「FHIR リソース」にコンフォーマントであると言明できます。その際、実装システムは以下のような課題を解決しなければなりません：

リソースＩＤ（メタデータの id プロパティ）の一貫性が保持されなければなりません。リソースはすべて、他のリソースからリファレンスされるための固有のＩＤを持ち、リファレンスされた時には対応するリソースに到達可能でなければなりません。どのようにリソースが交換されるときにも、リソースのＩＤは、リソース内部には保持されていないので、リソースとともに交換されなければなりません。
リソースへのリファレンスは該当するリソースに到達可能でなければなりません。これを実現する方法にはいろいろあり、関係するリソースは全てバンドルに含める方法、サービスコールのパラメータで関連するリソースを全て渡す方法、リファレンスされたリソースには全てアクセスできるようにするリソースリポジトリを前提にする方法などがあります。
リソースのメタデータに含まれる、"Version Id" および "Last Modified Date" アトリビュートが、リソースのバージョンおよび同時性の問題の解決のために、機構上および人手の観点から提供されること。ほとんどのリソース利用のコンテクストでは、この 2 つのアトリビュートのうち、両方でなければ少なくとも 1 つは必要で、実装フレームワークは、これらの情報をいつ、どのように交換するか決定しなければなりません。
コンフォーマンス宣言により、リソースを生成したり読み込んだりするアプリケーションが、リソースの使用法やコンテンツに関するルールを記述できること。実装システムは、このコンフォーマンス宣言あるいはそれに相当するものが、どのようにリソースの交換／保存のコンテクストに当てはめられるか、記述できるようになっている必要があります。
データ入力者、データ生成者、責任者および同意や承認といったトランザクションに関する情報が、どのように扱われるか。

サービス仕様では、上記の課題に対する解決方法が記述され公開される必要があります。

リソースＩＤの管理（§2.0.3）

すべてのリソースは明示的に個々を特定できるＩＤを持ちます。ＩＤはリソースの内部には格納されませんが、リソースを取り扱うシステムによって一貫性が保たれる必要があります。RESTful のシステムでは、リソースのＩＤは、最初にアクセスされた URL と同一になります。リソースがバンドルにパッケージされた時には、ＩＤはリソースとともに格納されます。FHIR のリソースを実システムで利用するときには、リソースＩＤの管理が必要になります。

リソースはいろいろな環境で利用されます。一般的にリソースの利用環境は 3 つに分類できます：

独立した業務システム：リソースが、病院のようなしっかりした管理下に置かれたコミュニティで、固定されたシステムの間でのみ交換される場合。いずれのリソースのタイプに対してもマスターのサーバーはひとつしかなく、そのサーバーでリソースが管理されます。このコンテクストでは、リソースの logical id だけで、リソースＩＤ管理の用が足ります。
世界規模の RESTful システム：同等な機能を持ったたくさんのサーバーが、それぞれ違ったタイプのリソースを管理する場合。リソースを特定するには、生成したサーバーの URL のフルパスが必要になります。
限定的な相互連携を行う独立した業務システム：上記の中間で、しっかりした管理下の業務コミュニティでありながら、他の独立した業務コミュニティのシステムあるいは世界規模の RESTful システムあるいはその両方と管理された情報交換も行う場合。実際には、この組み合わせが今現実に存在する医療情報システムの一番ありふれた姿であると思われます。

上記のような組み合わせが存在することから、独立した業務システム間で限定的な相互連携をシームレスに行うために、相対（論理）リファレンスと絶対リファレンスのいずれもが許容され、logical id が必須となっています。

リソースの複製と新規ＩＤの発行（§2.0.3.1）

リソースがシステム間でやり取りされる時には、新規ＩＤの発行（新規リソースの割り当て）が行われるときがあります。リソースへの新規ＩＤの発行が行われた時には、リソースの中の情報には一切変更はありませんが、そのリソースに対するリファレンスは全て更新される必要があります。新規ＩＤの発行が必要かどうかはコンテクストに依存し、リファレンスの更新方法も同じくコンテクストに依存します。

通常、クライアント／受け取り側のシステムでは、サーバー／送り出し側のシステムでのリソースのＩＤを、相対／絶対の別に関わらず、そのまま受け取ります。クライアント／受け取り側のシステムがリソース・リファレンスを辿る場合は、server id を使って（普通は http か、バンドルの中のリソースを特定する事で）行います。そのような場合には、リソースへの新規ＩＤの発行は必要ありません。

もうひとつのシナリオは、クライアントがサーバーからリソースを取得し、永続的なローカル・コピーを生成する場合です。ローカルのリソースが、独立したライフサイクルを持つ場合（つまり、キャッシュとしてのリソースではない場合）は、独自のＩＤを持つ必要があります。つまり、新規ＩＤの発行が必要です。一番単純な場合は、クライアントが単一のサーバーからのリソースのローカルコピーしか持たない場合です。この場合は、クライアントは、リソースの root の URL を入れ替え、logical id をそのままにするだけでよいのです。実際、サーバーが相対リファレンスを使っている場合には、この変更はリファレンスに何ら実際の変更を必要とせず、リファレンスの読み替えだけで事足ります。

しかしながら、クライアントは複数のサーバーにアクセスする場合があります。このような場合は、リソースの logical id の非重複性が保証されません。（すべてのリソースが logical id に UUID を使用しない限り。これは可能ですが、必須ではありません。）クライアントがリソースのＩＤの非重複性を保証できないときは、リソースへの新規ＩＤの発行が必要になります。実運用上、このことは、クライアントはＩＤ変換テーブルを保持し、ローカルにコピーしたリソースをリファレンスしている他のリソースを受け取った時には、そのリファレンスを更新しなければいけないということになります。

リソースをあるシステム空間から別のシステム空間にコピーするゲートウェー・システムの場合もよく似ています。ごく限られた場合には、ある閉じたシステムから別の閉じたシステムにリソースをコピーする際、ゲートウェーで logical id を処理せずそのまま通すことができます。しかしながら、もっと複雑な場合には、ゲートウェーを通過するリソースに対して、リソースへのリファレンスの修正が必要になります。

リソースを用いたワークフロー（§2.0.4）

ある特定のワークフローをシステムに実装する方法は何通りもあり、実際の業務システムの構築にリソースを用いる方法も何通りもあります。

RESTful の技法を使って、リソースをひとつひとつ http 通信で直接、この仕様で定められた方法でやり取りする方法。実装には、プッシュ型、プル型またはその両方の混合のいずれも使用できます。
リソースが、メッセージ交換や他の SOA の実装技術を用いて、そのコンテンツやパラメータとしてやり取りされる方法。
リソースが、自己完結してリンクされたリソースを全て内包するドキュメントとして「バンドル」され、そのドキュメント単位でやり取りや保持される方法。
リソースを HTML のページやコンテンツ・フィードのようなその他のウェブのコンテンツに埋め込まれる方法。

アイコン（§2.0.4.1）

すべての FHIR の（コンフォーマントな？）実装には、以下の FHIR アイコンを使用することができます。お好きなサイズをお選びください。

注意：FHIR は、正式な HL7 標準として投票される以前の、現在開発中のドラフト仕様です。

実装者がここで定義されている内容での試験実装を行うことは歓迎されていますが、内容が事前の通知無しで変更される可能性があることを明記して下さい。