InterSystems FHIRサーバーのカスタマイズとファサード

記事

Toshihiko Minamoto · 23 hr 前 25m read

#API #FHIR #JSON #REST API #ビジネスサービス #フレームワーク #相互運用性 #HealthShare #InterSystems IRIS for Health #Health Connect

FHIRサーバー

FHIRサーバーとは、FHIR（Fast Healthcare Interoperability Resources）標準を実装するソフトウェアアプリケーションであり、医療システムが標準化された方法で医療データを保存、アクセス、交換、および管理することができるようにします。

Intersystems IRISは、以下のFHIRリソースを保存および取得できます。

リソースリポジトリ – IRISネイティブのFHIRサーバーは、FHIRバンドルやリソースをFHIRリポジトリに容易に直接保存することができます。
FHIR Facade – FHIRファサードレイヤーは、既存のもの（多くの場合、FHIR以外）の上にFHIRに準拠したAPIを公開するために使用されるソフトウェアアーキテクチャパターンです。さらに、すべてのデータをFHIRネイティブシステムへ移行せずに、電子健康記録（EHR）、レガシーなデータベース、HL7 v2メッセージストアなどの医療データシステムを合理化します。

FHIRとは？

Fast Healthcare Interoperability Resources（FHIR）は、HL7 Internationalによって作成された標準化されたフレームワークであり、柔軟かつ開発者に優しい最新の方法で医療データの交換を促進します。さまざまな医療システム間のシームレスな統合と通信を実現するために、最新のウェブ技術を活用しています。

主なFHIRテクノロジー

RESTful API：リソースのやり取りに使用されます。
JSONとXML：データ表現のために使用されます
OAuth2：安全な認可および認証のために使用されます。

FHIR は、リソースと呼ばれるモジュール化されたコンポーネントを中心に構成され、それぞれが特定の医療概念を表しています。以下のようなものが含まれます：

患者：人口統計情報および識別子。
観察：臨床測定値（例：バイタルサイン、検査値）。
受診：患者と医療提供者のやり取り。
医薬品、アレルギー不耐性、病状など

FHIRファサード：

FHIRファサードとは、既存のFHIR以外のシステム（例えば、レガシーのEHR、HL7 v2ストア、カスタムデータベースなど）の上にFHIR準拠のAPIを提供するアーキテクチャ層であり、データをFHIR形式で直接保存する必要はありません。

これにより、既存のバックエンドインフラストラクチャを維持しながら、レガシーデータをオンデマンドでFHIRリソース形式（JSONまたはXML）に変換し、相互運用性を促進できます。

FHIRファサードは、FHIRリソースの送受信を行いますが、リソースリポジトリにデータを保存することなく、事前に構築されたFHIRサーバーアーキテクチャに依存しています。そのため、自身のロジックに対して粒度の高いレベルでの制御が可能になります。

IRIS FHIRファサードアーキテクチャ

HS.FHIRServer.RestHandler：このクラスは、クライアントシステムから送信されるすべてのFHIRリクエストを受信および処理し、それらをHS.FHIRServer.Serviceクラスにディスパッチして後続の処理を行います。
HS.FHIRServer.Service：このコアのシングルトンクラスは、FHIRリソースとバンドルの処理を担当します。受信リクエストのタイプを識別し、以下の宛先へ適切にルーティングします。

FHIRインタラクション：HS.FHIRServer.Storage.JsonAdvSQL.Interactionsによって処理されます。これはInteractionsクラスであり、主要なインタラクションのハンドラーとして機能します。
バルクFHIRバンドルトランザクション：HS.FHIRServer.DefaultBundleProcessorによって管理されます。
FHIRオペレーション： HS.FHIRServer.API.OperationHandlerによって処理されます。

FHIRファサードの実装

InterSystems IRISでFHIRサーバーを作成してFHIRファサードを実装するための前提条件

InterSystems IRISでFHIRサーバーを作成して、FHIRファサードを実装する前に、以下の構成が適切に設定されていることを確認してください。

必要なネームスペースでFHIRファンデーションを構成し、有効化する。
以下のクラス含む、FHIR実装クラスをカスタマイズする
- RepoManager
- InteractionStrategy
- Interactions

FHIRファンデーションの構成

ステップ1：FHIRファンデーションを有効化する

まずは、FHIRファンデーションを有効化する必要があります。これを行うには、以下の手順に従います。

システム管理ポータルでHSLIBネームスペースに切り替えます。
ヘルスメニューに移動します。

利用できるファンデーションネームスペースのリストが表示されています。

このデモでは、例としてLEARNINGネームスペース（データベース）を使用します。

画面上部で、「Installer Wizard（インストーラーウィザード）」をクリックし、ファンデーションネームスペースのステータスを表示します。
ネームスペースが次のようにマークされていることを確認します：「有効化済み」。そうでない場合は、「Activate（有効化）」ボタンをクリックして有効にします。

ファンデーションネームスペースの手動による構成

ネームスペースが「インストーラーウィザード」ページに表示されていない場合、以下の手順に従って手動で構成できます。

「Configure Foundation（ファンデーションを構成）」をクリックします。
必要な詳細を入力します。
ネームスペースを有効化します（例えば、たった今構成したネームスペース）。

注意：ファンデーションネームスペースを追加する前に、以下の前提条件を満たしていることを確認してください。

すべてのHealthShare（HS）パッケージ、ルーティン、グローバル*がターゲットのネームスペースに正しくマッピングされている。
すべての必要なロールが作成され、適切に割り当てられている。

そうでない場合は、構成中に予期しないエラーが発生する場合があります。

構成後、ファンデーションリストでネームスペースを確認できます。

プログラムによるファンデーションの構成

以下のinstallクラスメソッドを実行します。

Do ##class(HS.Util.Installer.Foundation).Install(“FoundationNamespace”)

よくできました！ファンデーションネームスペースが正常に構成され、有効化されました！この設定が完了したら、次に進みましょう。

すべての構成に関連するアクティビティは自動的にログファイルに記録されるため、構成プロセス中に問題が発生した場合は、トラブルシューティングのためにログファイルを参照できます。（詳しくは、「構成のためのHSログファイルの解析」セクションをご覧ください。）

次のステップでは、FHIR実装クラスをカスタマイズして、特定の統合と処理要件を満たします。

FHIR実装クラスのカスタマイズ

IRIS FHIRサーバーのアーキテクチャは、リソースリポジトリの拡張やカスタムバックエンドの実装にかかわらず、FHIR実装クラスを柔軟にカスタマイズできます。以下の2つの方法でカスタマイズが可能です。

Facade（ファサード）アプローチ（推奨）：事前に作成されたFHIRクラスをカスタマイズして、FHIRリソースと直接やり取りできます。この手法は、FHIRインターフェースを通じて基盤システムを抽象化することにより、ファサードデザインパターンに準拠しています。
Interoperability Routing（運用相互性ルーティング）アプローチ：リクエスト処理の処理段階でIRIS Interoperabilityにリクエストを転送するように、FHIRサーバーを構成できます。これにより、カスタムロジックとルーティングのために相互運用性コンポーネントを活用できます。このアプローチでは、FHIRサーバーの設定内にある「Service Config Name」で、Interoperabilityサービスクラスを直接構成できます。そうすると、FHIR サーバーはリクエストをInteroperabilityの本番環境へリダイレクトします。

注意：このInteroperability Routingメソッドでは、HS.FHIRServer.Interop.Serviceまたはそのサブクラスのみがサポートされています。 IRISでは、他の一般的なビジネスサービスクラスは使用できません。

一般的に、Interoperabilityの本番環境がないFHIRサーバーのリソースリポジトリは、著しく高速なパフォーマンスを実現できます。

では、カスタムクラスの作成に進みましょう。

クラスで事前構成をカスタマイズする

FHIRサーバーのカスタマイズを開始するには、いかにリストされているクラスのサブクラスを作成します。サブクラスの動作は、特定のニーズに合わせて、パラメーターを調整、ロジックを変更、または機能を書き換えることで変更できます。

注意：IRIS 2024.1バージョン以降、統合ロジックが更新されました。新しい実装の詳細については以下をご覧ください。後方互換性を保つため、従来のクラスと更新されたクラスの両方が引き続き利用可能です。しかし、最新バージョンで作業する場合、更新された実装を使用することをお勧めします。

バージョン2024.1以降：

2024.1以前のバージョンの場合：

リソースリポジトリを採用する代わりに、FHIR サーバーアーキテクチャを処理する完全なカスタムバックエンドロジックを記述する場合は、アーキテクチャのスーパークラスを継承する必要があります。

クラスをカスタマイズする前に、まずはFHIRインタラクションの概念を理解しておきましょう。

FHIRインタラクションとは？

FHIRインタラクションは、クライアントがRESTful API経由でFHIRリソースに対して実行できるFHIR（Fast Healthcare Interoperability Resources）仕様によって定義された標準的な操作です。

これらのインタラクションは、クライアントとサーバーがどのようにやり取りするのかを定義し、やり取りにはFHIRリソースとして表現された医療データの取得、作成、更新、または削除が含まれます。

一般的なFHIRインタラクション

以下に、FHIRインタラクションの主なタイプをリストしました。

Read：IDによってリソースを取得する（例：GET /Patient/123）。

Vread：リソースの特定のバージョンを取得します（例： GET /Patient/123/_history/2）。

Update：既存のリソースを置換します（例：PUT /Patient/123）。

Patch：リソースを部分的に更新します（例：PATCH /Patient/123）。

Delete：リソースを削除します（例：DELETE /Patient/123）。

Create：新しいリソースを追加します（例：POST /Patient）。

Search：パラメーターに基づいてリソースをクエリします（例：GET /Patient?name=Ashok）。

History：リソースまたはリソースタイプの変更履歴を取得します（例：1つのリソースの場合は、GET /Patient/123/_history、すべてのリソースの場合は、GET /_history）。

Capabilities： FHIRサーバーが何をサポートできるのかを表示するCapabilityStatementを返します（例：GET /metadata）。

引き続きクラスをカスタマイズしましょう。

これら3つの主要なクラスは階層的な関係を形成しており、互いに連携しながら、FHIRサーバー実装の基盤となるインフラストラクチャを構築します。

Interactionクラス

HS.FHIRServer.Storage.JsonAdvSQL.Interactions は、InteractionsStrategyクラスによりFHIRインタラクションを処理するためのバックボーンとしての役割を果たす中核となるクラスです。サービスクラスとリソースリポジトリの間のやり取りを促進します。

このクラスは、リソースレベルでFHIRリポジトリとやり取りするAPIメソッドを提供します。

Add()：FHIRリポジトリで新しいリソースを作成し、保存します。
Delete()：リポジトリから既存のリソースを削除します。
Read()：リポジトリから特定のリソースを取得します。
LoadMetadata()：Capability Statementを定義するために使用されるメタデータをロードします。（構成の詳細については、「Capability Statementの変更」セクションをご確認ください。）

これはメソッドの完全なリストではありません。

FHIRリクエストの処理時にService（HS.FHIRServer.Service.cls）クラスから呼び出されるInteractionsクラスのメソッドは、サーバーサイドのObject Scriptアプリケーションから直接呼び出すこともできます。例えば、サービスにPOSTリクエストを送信する代わりに、サーバーサイドのアプリケーションはサービスにPOSTリクエストを送信するのではなく、InteractionsクラスのAdd()メソッドを呼び出すことができます。

Interaction Strategyクラス

HS.FHIRServer.JsonAdvSQL.InteractionsStrategyクラスは、FHIRサーバーの全体的な戦略とバックエンドロジックを定義します。ストレージ戦略として機能し、 FHIRリソースの保存および取得方法を決定します。

各InteractionsStrategyはHS.FHIRServer.API.RepoManagerのサブクラスに関連付けられており、この戦略に対応するサービスを管理します。

さらに、以下にあるInteractionsStrategyクラスで2つのパラメーターを構成する必要があります。

StrategyKey：InteractionsStrategyとRepoManagerの両方によって使用される一意のキーを割り当てます（例： Parameter StrategyKey As %String = "MyFacade"）。

2. InteractionsClass：使用するカスタムのInteractionクラスを指定します（例：Parameter InteractionsClass As %String = "FHIRFacade.Storage.JsonAdvSQL.Interactions"）。

Repo Managerクラス

HS.FHIRServer.Storage.JsonAdvSQL.RepoManagerリソースリポジトリは、FHIRサーバーのデフォルトのストレージ戦略です。追加の開発タスクなしに、完全に機能するFHIRサーバーをインストールできます。このRepoは、サーバーが受信したFHIRデータを自動的に保存します。このクラスは新しいリポジトリを作成し、FHIRデータベースを構成し、戦略を構築します。

さらに、以下にあるRepoManagerクラスのパラメーターを構成する必要があります。

StrategyKey：InteractionsStrategyとRepoManagerの両方によって使用される一意のキーを割り当てます。

Interactionsクラスのカスタマイズ

処理を開始するために、まずはInteractionsクラスを見てみましょう。

カスタムクラスを作成する： HS.FHIRServer.Storage.JsonAdvSQL.Searchクラスを拡張して、カスタムの動作を定義します。
特定のリソースタイプに対してAdd() ソッドをオーバーライドする：リソースをデフォルトのリポジトリに保管する代わりに、処理をカスタム実装へリダイレクトします（例：resourceTypeが「Patient」の場合）。そのためには、カスタムクラスでAdd()メソッドをオーバーライドします。
リソースオブジェクトで必要なメタデータを設定する：このカスタマイズの一部として、特定のメタデータフィールドがpResourceObjで設定されていることを確認してください。そうしないと、予期しないエラーが発生する場合があります。必要なフィールドには以下のものが含まれます。
```
Set pResourceObj.meta = {}
Set pResourceObj.meta.versionId = 1
Set pResourceObj.meta.lastUpdated = $ZDT($H, 3, 7)
```

これは、FHIRサーバーが正しく機能するために必要な、リソースの適切なバージョン管理とタイムスタンプを保証します。

Include HS.FHIRServer
Class MyFacade.HS.FHIRServer.Storage.JsonAdvSQL.Interactions Extends HS.FHIRServer.Storage.JsonAdvSQL.Search
{
Method Add(pResourceObj As %DynamicObject, pResourceIdToAssign As %String = "", pHttpMethod = "POST") As %String
{
    If pResourceObj.resourceType="Patient" {
        Set sc = ##class(MyFacade.FHIRFacade.Patient.Utils).Create(pResourceObj)
        If $$$ISOK(sc) {
            Return pResourceObj.Id
        }
    }
    Else {
        $$$ThrowFHIR($$$HSFHIRErrResourceNotSupported,pResourceObj.resourceType)
    }
    }
}

/// My custom class to handle the FHIR resource. Here I can modify and store data into my classes/global 
Class MyFacade.FHIRFacade.Patient.Utils Extends %RegisteredObject
{

ClassMethod Create(pResourceObj)  As %Status
{
    ///
    /// Store logic 
    /// You have to set the values below as mandatory key-value pairs in pResourceObj
    Set pResourceObj.Id=11
    Set pResourceObj.meta = {}
    Set pResourceObj.meta.versionid=1
    Set pResourceObj.meta.lastUpdated = $ZDT($H,3,7)
    Set pResourceObj.meta.LastModified = $ZDT($H,3,7)
}

}

注意：IRISでは、FHIRサーバーが構成され有効化されると、全体的なパフォーマンスの向上させるために、StrategyInteractionsとInteractionクラスのインスタンスを意図的にキャッシュします。

次のカスタマイズのステップに進む前に、CapabilityStatementが何であるか、そしてそれをFHIRサーバー向けにどのように定義するかを理解しておくことが重要です。

Capability Statement

FHIRサーバーのCapability Statementは、FHIRサーバーがサポートする機能を記述したクライアント向けのメタデータです。 FHIRクライアントが取得できる、サーバーの動作、対応している操作、およびFHIRリクエストの処理方法に関する詳細が含まれています。

FHIRサーバーのCapabilityStatementのカスタマイズ

FHIRサーバー（FHIR Facade）をカスタマイズする場合、FHIRクライアントがその機能の正確な説明を取得できるように、Capability Statementも更新する必要があります。その方法には2つのオプションがあります。

通常、メタデータリソース（your_FHIRServer_URL/metadata）を使用してサーバーに対してREST APIを呼び出すことで、CapabilityStatementにアクセスできます。

例：GET http://127.0.0.1:52782/fhirapp/r4/metadata

InterSystems IRISには、FHIRサーバーアーキテクチャのCapabilityStatementをカスタマイズするための2つの方法があります

1. カスタムのInteractionStrategyクラスのメソッドをオーバーライドする（推奨）

これは、CapabilityStatementの生成方法をより細かく制御できるため、推奨される最も柔軟な方法です。

CapabilityStatementは、パフォーマンスを向上させるために、特定のFHIRサーバーの動作が変更され、キャッシュされた場合に自動的に再生成されます。そのため、通常、FHIRサーバーの有効化や無効化などの際に生成されます。

IRISは、CapabilityStatementの異なる部分を更新するためにいくつかのメソッドを提供しています。主なメソッドは以下のとおりです。

GetCapabilityTemplate()

このメソッドは、基本的な詳細をカスタマイズするために使用されます（例：名前、バージョン、パブリッシャー、説明、ステータスなど）。カスタムのInteractionStrategyクラスでGetCapabilityTemplate()メソッドをオーバーライドして、実装に合った変更済みの構造を返すこともできます。

LoadMetadata()

このメソッドはInteractionsクラスの一部で、CapabilityStatementを生成するために、InteractionStrategyクラスによって呼び出すことができます。

カスタムのCapabilityStatementは、このメソッド内で直接設定するか、別のクラスにロジックを委譲して、LoadMetadata()内から呼び出すことで構成できます。

カスタマイズの例

LoadMetadata()メソッドを以下のようにカスタマイズしました。

CapabilityStatementを定義して保持するために、カスタムのクラス（FHIRFacade.Utils）を作成しました。
ステートメントを検証し、..metadataと..metadataTimeプロパティに保存しました。

Method LoadMetadata() As %DynamicObject
{
    #; get your capability statement by calling your class method
    Set metadata = ##class(FHIRFacade.Utils).FHIRFacadeCapabilityStatement()
    Set GLOBAL = ..strategy.GetGlobalRoot()
    if metadata="" {
        $$$ThrowFHIR($$$HSFHIRErrMetadataNotConfigured,$$$OutcomeIs(503, "fatal", "transient"))
    }
    if @GLOBAL@("capability", "time") '= ..metadataTime {
        Set ..metadata = ##class(%DynamicObject).%FromJSON(metadata)
        Set ..metadataTime = $Get(@GLOBAL@("capability", "time"),$ZDT($H,3,7))
    }
    Return ..metadata
}

FHIRサーバーのCapabilityStatementの更新

前述の通り、FHIRサーバーはパフォーマンス向上のためにCapabilityStatementをキャッシュします。つまり、設定や実装に加えた変更は、CapabilityStatementが明示的に更新されるまで反映されません。

CapabilityStatementを更新するには、以下の手順を実行します。

IRISターミナルを開いて、以下のコマンドを実行します。

DO ##class(HS.FHIRServer.ConsoleSetup).Setup()

メニューから、「Option 7: Update the CapabilityStatement Resource」を選択します。
更新したいFHIRエンドポイントを選択します。
プロンプトが表示されたら更新を確認します。

または、以下にあるクラスメソッドを使用して、CapabilityStatementを更新することもできます。

ClassMethod UpdateCapabilityStatement(pEndPointKey As %String = "/csp/healthshare/learning/fhirmyfac/r4")
{
    #dim strategy as HS.FHIRServer.API.InteractionsStrategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint(pEndPointKey)
    if '$IsObject(strategy) {
    $$$ThrowFHIR($$$GeneralError, "Unable to create Storage Strategy Class")
    }
    Set interactions = strategy.NewInteractionsInstance()
    do interactions.SetMetadata( strategy.GetMetadataResource() )
}

CapabilityStatementの手動による編集

FHIRサーバーエンドポイントのCapabilityStatementを手動で取得、変更、およびアップロードできます。このアプローチにより、ステートメントの構造とコンテンツを完全に制御できます。

CapabilityStatementを取得してエクスポートするための手順：

FHIRエンドポイントのインタラクション戦略を取得する。
新しいインタラクションインスタンスを作成する。
既存のCapabilityStatementをロードする。
ローカルのJSONファイルにエクスポートする。

ClassMethod UpdateCapabilityStatamentViaFile()
{
    Set strategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint("/fhirapp/r4")
    Set interactions = strategy.NewInteractionsInstance()
    Set capabilityStatement = interactions.LoadMetadata()
    Do capabilityStatement.%ToJSON("c:\localdata\MyCapabilityStatement.json")
}

5. 構成に従って、エクスポートしたJSONファイルを編集する。編集したら、FHIRサーバーに更新されたCapabilityStatementをロードするために以下のコードを実行します。

ClassMethod LoadCapabilitystatmentToFHIR(){ 
      set strategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint("/fhirapp/r4")
      set interactions = strategy.NewInteractionsInstance()
      set newCapabilityStatement = {}.%FromJSONFile("c:\localdata\MyCapabilityStatement.json")
      do interactions.SetMetadata(newCapabilityStatement)
}

FHIRサーバーの構成

FHIRサーバーエンドポイントを構成する

このドキュメントで参照されているバージョン2025.1では、FHIR構成インターフェースと設定プロセスが大幅に変更されました

2025.1：FHIRエンドポイントを追加するには、次の順に移動します：IRIS Management Portal → Health > FHIR Server Management > FHIR Configuration
- URL：/csp/healthshare/learning/fhirfac/r4
- ネームスペース：お使いのネームスペースを選択してください
- FHIRバージョン：FHIRバージョンを選択してください

2025.1以前のバージョン：ナビゲーションパスは、 IRIS Management Portal → Health > FHIR Configuration。エンドポイントの例：/csp/healthshare/learning/fhirfac/r4

高度な構成

「Advanced Configuration（高度な構成）」セクションでは、必要な詳細を入力した後に、カスタムのInteraction Strategyクラスを定義できます。

追加の構成

必要に応じて、以下の設定を構成できます。設定しない場合、システムはデフォルトの値を使用します。

最後に、「Create（作成）」をクリックして構成プロセスを開始します。システムは以下のタスクを実行するため、しばらく時間がかかる場合があることに注意してください。

FHIRサーバーのデータベース設定

リソースデータベース：現在のFHIRリソースを保存します。

履歴データベース：リソースの過去のバージョンを保持します。

この設定では、リソースを保存するために複数のデータベースが作成されます。

グローバルマッピングと追加の構成：システムは、グローバルマッピングを自動的に確立し、FHIRサーバーに必要な追加の構成設定を適用します。

これで、システムはFHIRリクエストを受け取り、それに応じたレスポンスを送信する準備ができました。

構成のためのHSログファイルの解析

ファンデーションネームスペース有効化のログファイル

インストーラーウィザードでファンデーションネームスペースを有効化中、InterSystems IRISは一連のログファイルを自動的に生成します。これらのファイルには、FHIRサーバーに必要な基盤コンポーネントの設定中に実行されたアクションの詳細な情報がキャプチャされます。

これらのログは、以下の情報を通常含んでいるため、構成プロセスの理解やトラブルシューティングに非常に重要です。

FHIRサーバー構成に関連する上位レベルのインストールイベント。
ネームスペース固有の構成詳細。それぞれのターゲットネームスペースで設定または変更した内容を表示。

ログファイル名にはパターンがあります。 HS.Util.Installerで始まり、その後にネームスペース名、ハイフン（-）、整数、および.log拡張子が続きます。例：HS.Util.Installer.HSSYS-0.log。

注意：整数カウントは、ファンデーションが有効化されるたびにインクリメントされます。

これらのディレクトリをプログラムで取得するには、以下の手順を実行します。

$system.Util.InstallDirectory()を使用して、IRISインストールディレクトリを取得します。
$system.Util.ManagerDirectory()を使用して、/mgr/ディレクトリへのフルパスを取得します。

一般的なログファイル：

HS.Util.Installer.1.log
HS.Util.Installer.HSSYS-0.log
HS.Util.Installer.HSCUSTOM-0.log
HS.Util.Installer.HSLIB-0.log
HS.Util.Installer.HSSYSLOCALTEMP-0.log

インストールや構成中に問題が発生した場合は、詳細な診断情報を得るためにこれらのログファイルを確認してください。

注意： IRISのアップグレード後は必ずこれらのログファイルを確認し、エラーがないことを確認してください。

さらに、Open Exchange上のIRISFHIRServerLogsアプリケーションは、これらのログファイルを確認するためのWebインターフェースを提供します。

FHIRサーバーのデバッグ

InterSystems IRISは、FHIRサーバーのデバッグを簡単にするためにデバッグモードを提供しています。

InterSystems IRIS FHIRサーバーのクラスキャッシュについて理解する

InterSystems IRISでは、FHIRサーバーが構成され有効化されると、全体的なパフォーマンス向上のために、StrategyInteractionsやInteractionクラスのインスタンスを意図的にキャッシュし始めます。

しかし、このキャッシュメカニズムのため、一旦クラスがキャッシュされると、サブクラスに加えた変更は反映されなくなります。つまり、FHIRサーバーがこれらのクラスの新しいインスタンスを作成しない限り、カスタムロジックへの更新は反映されません。

開発やテスト中に変更を反映させるためには、デバッグモードを有効にすると、サーバーが各リクエストごとに新しいインスタンスを生成することを強制します。

IRISシェルによるデバッグモードの有効化

IRISターミナルを使用してデバッグモードを有効化するには、以下の手順を実行します。

IRIS Terminalを開いて、以下のコマンドを実行します。

Do ##class(HS.FHIRServer.ConsoleSetup).Setup()

メニューから、「FHIRサーバーエンドポイントを構成」を選択します。
プロンプトが表示されたら、設定したいエンドポイントを選択してください。「FHIRサービス構成を編集」セクションで、デバッグモード設定を見つけます。つぎに、値を0から7に変更して完全デバッグモードを有効化します。

この設定は以下も有効にします。

認証されていないアクセスを許可
リクエストごとに新規サービスインスタンスを作成
レスポンスにトレースバックを含める

構成を保存します

Capability Statementの更新

Do ##class(HS.FHIRServer.ConsoleSetup).Setup() コマンドは、多用途なツールであり、デバッグ目的に限定されるものではありません。以下でも使用できます。

FHIRエンドポイントの構成、更新、サービス終了。
Capability Statementの更新

役立つマクロ、クラス、およびグローバル

マクロ

$$$ThrowFHIR：サーバーロジック内でFHIR準拠の例外をスローするために使用されます。
$$$HS*：FHIR関連の標準的なエラーメッセージを定義するマクロのセット。

クラス

HS.FHIRServer.Installer：インストールに関連するクラスメソッドを提供します。
HS.FHIRServer.Tools.CapabilityTemplate：FHIR CapabilityStatementの構築およびカスタマイズのためのテンプレートとヘルパーメソッドを提供します。
HS.FHIRServer.API.OperationHandler：サーバーでのカスタムのFHIR操作を管理します。
GetMetadataResource()：カスタムクラスでこのメソッドをオーバーライドする場合、FHIRサーバーによって返されるCapabilityStatementを変更または拡張します。
HS.Util.Installer.Foundation
HS_HC_Util_Installer.Log：HS.Util.Installer.*.logファイルからの詳細を内部で保存します。

グローバル

^HS.FHIRServer.*：FHIRサーバーの構成データおよびリソースインスタンスを保存します。
^FSLOG：監査とデバッグのためにFHIRサーバーログエントリを保存します。 FSLog Open Exchangeアプリケーションは、これらのログのWebベースのビューを提供します。
^%ISCLOG：さまざまなレベルでHTTPリクエストログを有効化します。以下は詳細なログを有効にする方法の例です。

ログを有効化する：

Set ^%ISCLOG = 5

Set ^%ISCLOG("Category","HSFHIR") = 5

Set ^%ISCLOG("Category","HSFHIRServer") = 5

ログを無効化する：

set ^%ISCLOG=1

^FSLogChannel：ファンデーションネームスペースでログを有効化します。このグローバルは、キャプチャする必要があるログのタイプを指定します。 ^FSLogChannelを設定すると、システムは^FSLOGグローバルでログを保存し始めます。ログを無効化するには、global kill ^FSLogChannelを削除します。

利用可能なchannelTypeの値には、「Msg」、「SQL」、「_include」、および「all」が含まれます。

例：^FSLogChannel("all") = 1に設定。すべてのチャンネルタイプのログ記録を有効化します。

一般的なエラーと解決策

ファンデーションでの「クラスが存在しません」エラー：

すべての設定が正しく行われていても、以下のエラーが発生することがあります。エラーが発生した場合、以下を確認することを覚えておいてください：

すべての%HS_DB_*ロールが作成されており、ファンデーションネームスペースに適切にマッピングされていることを確認してください。
HSSYSネームスペースとターゲットネームスペースの両方のHS.Util.Installer.* ログファイルを確認します。o

この記事は、基本的なFHIRファサード構成の概要を提供します。

@Ashok Kumar Tさんが書いた元の記事へ