Skip to main content

This documentation is for an older version of this product. See the latest version of this content.Opens in a new tab

アーキテクチャ

アーキテクチャ

リソース・リポジトリを使用する FHIR サーバとカスタムのバックエンドを使用する FHIR サーバは、同じアーキテクチャを使用します。FHIR サーバを通じて FHIR 要求をトレースすると、このサーバのアーキテクチャに関する主要機能の概要を適切に理解することができます。最初に、FHIR 要求はサービスに到達する必要があります。サービスは、要求がサーバの FHIR メタデータ標準に適合していることを確認してから、要求の処理に適したコンポーネントに要求をルーティングします。FHIR 要求は、このサービスに 3 つの方法で到達できます。REST ハンドラから到達する方法、相互運用プロダクション経由で到達する方法、または ObjectScript FHIR クライアントから到達する方法です。このサービスは、相互運用プロダクションのビジネス・サービスとは無関係です。

サービスが要求をどのように処理するかは、要求のタイプによって異なります。

  • FHIR 相互作用Opens in a new tabに対応する HTTP メソッドとエンドポイントが要求に含まれる場合、サービスは、そのタイプの FHIR 相互作用を処理する Interactions クラスのメソッドに、その要求を転送します。例えば、read 相互作用が含まれる要求は、Interactions クラスの Read() メソッドに送信されます。この Interactions クラスは、InteractionsStrategy クラスを使用して FHIR 相互作用を実行し、FHIR サーバの全体的な目的に従って相互作用を処理します。

  • FHIR オペレーションOpens in a new tabの場合、サービスは、オペレーションを実行するために設計された特別なクラスに要求を転送します。リソース・リポジトリを使用する FHIR サーバでは、特定の FHIR オペレーションのサポートがすぐに利用可能です。

  • タイプが transaction または batch のバンドルOpens in a new tabが要求に含まれる場合、サービスは、バンドルをアンパックして個々の HTTP オペレーションを実行する特別なクラスに要求を転送します。

FHIR サーバの内部アーキテクチャ

サービスの詳細

サービスは、1 つのエンドポイントに対して自身の 1 つのインスタンスのみをインスタンス化できるシングルトン・クラスです。このインスタンス化は、最初の FHIR 要求が REST ハンドラまたはビジネス・オペレーションによってサービスに転送されたときに実行されます。インスタンス化されると、サービスは、プロセスが終了するまで存在します。FHIR 要求をプログラムによって実行するサーバ・アプリケーションの場合、アプリは、最初の要求を送信する前に、HS.FHIRServer.Service.EnsureInstance()Opens in a new tab を呼び出してサービスを取得する必要があります。

ほとんどの場合、Service クラス (HS.FHIRServer.ServiceOpens in a new tab) は、サブクラスを作成することなく、エンドポイントの FHIR 標準に準拠して要求をルーティングする準備ができています。FHIR サーバの動作を指定するカスタム・ロジックは、サービスにではなく、Interactions サブクラスおよび InteractionsStrategy サブクラスに記述します。

エンドポイント向けの新しいサービスの作成やサービスの削除など、サービスを管理するメソッドは、HS.FHIRServer.API.RepoManagerOpens in a new tab のサブクラスに属しています。

InteractionsStrategy の詳細

InteractionsStrategy クラスは、FHIR サーバの全体的なストラテジを規定します。これは、FHIR サーバ・アプリケーションのバックエンドで、FHIR データの処理環境を作成および実装します。InteractionsStrategy のスーパークラスは、HS.FHIRServer.API.InteractionsStrategyOpens in a new tab です。

多くの場合、InteractionsStrategy は、FHIR サーバが FHIR リソースを保存および取得する方法の "ストレージ・ストラテジ" です。例えば、リソース・リポジトリは、FHIR データの保存と取得に使用されるリソースとインデックス・テーブルを作成する HS.FHIRServer.API.InteractionsStrategyOpens in a new tab のサブクラスによって実装されます。FHIR データを保存しないアプリケーションの場合、このストラテジにより、外部の FHIR サーバ、またはサーバの FHIR データを操作する他のカスタム・ロジックと通信する環境を設定できます。

InteractionsStrategy は、InteractionsStrategy を使用するサービスを管理する HS.FHIRServer.API.RepoManagerOpens in a new tab のサブクラスに関連付けられています。

Interactions クラスの詳細

InteractionsStrategy クラスはアプリケーションのバックエンドですが、Interactions クラスを使用して、サービスが受信する FHIR 相互作用を実際に実行します。このプロセス中に、Interactions クラスは、特に FHIR サーバ・ストラテジ全体に共通する構造とロジックのために、InteractionsStrategy クラスのメソッドを呼び出すことがよくあります。このような相互依存関係があるため、統合アプローチでは、Interactions クラスと InteractionsStrategy クラスは同時にサブクラスが作成されます。Interactions のスーパークラスは、HS.FHIRServer.API.InteractionsOpens in a new tab です。

FHIR 要求を処理する際にサービスによって呼び出される Interactions クラスのメソッドは、サーバ側 ObjectScript アプリケーションから直接呼び出すこともできます。例えば、サーバ側アプリケーションから、POST 要求をサービスに送信する代わりに、Interactions クラスの Add() メソッドを呼び出すことができます。サービスをバイパスする場合、サーバ・アプリケーションは、サービスのメタデータによって FHIR サーバに設定された制約をバイパスできます。例えば、サービスを経由する要求に対してエンドポイントが読み取り専用であっても、サーバ・アプリケーションで FHIR サーバのストレージに入力することができます。

また、Interactions クラスは、FHIR オペレーションの実行、バンドルの処理、および FHIR データの検証のためにサービスで使用される特殊クラスの追跡も行います。サービスは、アクションが必要になると、Interactions オブジェクトからこれらのクラスの名前を取得します。

リソース・リポジトリNext section
FeedbackOpens in a new tab