血液検査の結果を見て、何が書いてあるのか全然わからないあの感じ、分かるかと思います。 その問題を解決してくれるのがFHIRInsightです。 そもそも医療データは怖いものや分かりにくいものではなく、誰もが活用できるものであるべきだ、という考えから始まりました。 血液検査は健康チェックではとても一般的ですが、正直なところ、理解するのは多くの人にとって難しく、臨床検査を専門としない医療スタッフにとっても難しいことがあります。 FHIRInsightは、血液検査のプロセスをもっと分かりやすくし、情報をより活用しやすくすることを目指しています。

🤖 FHIRInsightを構築した理由

すべては、シンプルながら強力なこの質問から始まりました。

「なぜ血液検査の結果を読むのは、時には医師にとってもこんなに難しいのか？」

血液検査の結果を見たことがあるなら、大量の数字、意味の分かりにくい略語、そして自分の年齢や性別、状態に合っているかどうかもわからない「基準範囲」を見たことがあると思います。 確かに診断ツールではありますが、状況が分からなければ、結局推測することになります。 経験豊富な医療従事者でさえ、すべてを理解するためにはガイドラインや論文、専門家の意見を照らし合わせる必要があることがあります。

そこで登場するのがFHIRInsightです。

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によって作成された標準化されたフレームワークであり、柔軟かつ開発者に優しい最新の方法で医療データの交換を促進します。

開発者の皆さん、こんにちは！

バージョン2025.1以降のIRIS for Healthの機能に、「OAuth FHIR Client Quickstart」が追加され  FHIR サーバーを OAuth2.0リソースサーバ―として簡単に設定できるようになりました。

この記事では、OAuth2.0 認可サーバーとして Auth0（Okta社 https://auth0.com/jp）を利用し、IRISに用意するFHIRサーバーを OAuth2.0 リソースサーバ―として設定し、Webアプリケーション（例ではPostman）からFHIRリソースにアクセスするまでの流れをご紹介します。

OMOP Odyssey - InterSystems OMOP、クラウドサービス（トロイ編）

Auth0 と InterSystems IRIS FHIR リポジトリ使った SMART On FHIR に関する連載最終回では、Angular 16 で開発したアプリケーションをレビューします。

このソリューションに定義されたアーキテクチャがどのように構成されているかを思い出しましょう。

フロントエンドのアプリケーションは 2 列目で、ご覧のように 2 つのことを行います。

1. ログインリクエストを Auth0 にリダイレクトし、レスポンスを受信する。
2. REST 経由でリクエストを FHIR サーバーに送信し、そのレスポンスを受信する。

Angular

Angular は TypeScript が開発し、Google が管理するオープンソースの Web アプリケーションフレームワークで、シングルページ Web アプリケーションの作成と管理に使用されます。 この「シングルページアプリケーション」デザイン手法によって、はるかに動的なユーザー向けアプリケーションを設計することができます。 最初の記事で説明したとおり、ここではアプリケーションサーバーとリバースプロキシとして NGINX を使用し、呼び出しヘッダーがサーバーの呼び出しヘッダーに一致するように変更して、CORS から派生する問題を回避します。

開発者の皆さん、こんにちは。

突然ですが、2024年6月25日に開発者向けセミナー「FHIR 新機能のご紹介～2024.1～」が開催されました。
ご視聴になられた方も多数いらっしゃると思います。
まだご視聴になられていない方は是非一度、ご覧になってみてください。
YouTubeリンク

さて、こちらのセミナーにおいてご紹介された、IRIS for Health 2024.1からの新機能「FHIR Object Model」を用いて、リポジトリタイプのInteroperability開発の具体的なサンプルを作成してみました。
自身の備忘のため、すぐ開発環境を構築できるよう、コンテナ環境かつGitHubの公開もしております。
利用方法は、GitHub内のREADMEを参照ください。
GitHubリンク

目次

1. 
   

   FHIR Object Modelとは？

2. 
   

   メリット・デメリットを深堀り

3. 
   

   GitHub公開ソースについて

4. 
   

   所感

1. FHIR Object Modelとは？

まずはFHIR Object Modelとはなにか、簡単に説明します。
FHIR Object Modelとは、FHIRリソースをオブジェクトモデル化したクラス群です。
IRIS for HealthでFHIR開発に多く携わっている方は、あれ？と思うわけです。
既に公開中のJSONテンプレートエンジンとなにが違うの？

前回の記事でSMART On FHIRプロジェクトのアーキテクチャを紹介したので、いよいよ本題に入り、必要となる全ての要素の設定を始めましょう。

まずはAuth0から始めます。

Auth0の設定

登録が完了したら、左側のメニューから最初のアプリケーションを作成します

この例では、Angular 16で開発されたアプリケーションなので、Single Page Web Applicationタイプとなります。このオプションを選択し、Createをクリックします。

次の画面では以下のフィールドを定義する必要があります。

• 許可されるコールバックURL：https://localhost
• 許可されるログアウトURL：https://localhost
• 許可されるWebオリジン：https://localhost
• クロスオリジン認証を許可する：チェック済
• 許可されたオリジン(CORS)：https://localhost

注意： URLはすべてHTTPSでなければなりません。これはOAuth2接続要件の1つです。

これはOAuth2接続の要件の1つです。これでAuth0が認証と認可プロセスの後にユーザーをリダイレクトするために必要なURLを設定しました。

はじめに

先日、@Patrick Jamieson が開催した素晴らしいハンズオンに参加してきました。そこでは、SMART On FHIR が定義したプロトコルに従って Angular アプリケーションを IRIS FHIR サーバーとともに構成したセッションでした。非常に深い興味を得たため、独自に Andular アプリケーションを開発し、そこから学んだことを活用してコミュニティに共有することにしました。

SMART On FHIR

SMART On FHIR について Google ではどのように説明しているのか見てみましょう。

SMART On FHIR は電子健康記録（EHR）システムの情報にアプリケーションがアクセスできるようにするためのデータ規格です。 アプリケーション開発者は、その規格を採用した EHR システムに接続する単一のアプリケーションを作成できます。

SMART On FHIR では、以下の主な概念を処理します。

• OAuth2 または OpenID による代理認証と承認。
• 定義されたコンテキストにおける FHIR リソースの操作。
• HTTPS 通信。

プロジェクトのアーキテクチャ

この演習では、Docker と Auth0 サービスの両方で以下の要素を構成しました。

• フロントエンドとして機能する Angular で開発されたアプリケーション。

前回の記事では特定の HIS のデータベースに格納されたリソースを取得する方法を確認したので、今回は、HIS に、システムで受け取る FHIR リソースを起点とする新しいレコードを追加する方法を説明します。

FHIR の CRUD 操作

FHIR の主な機能の 1 つに、Rest API による CRUD 操作のサポートがあります。つまり、FHIR と連携するすべてのシステムには、GET、POST、PUT、および DELETE タイプの HTTP 呼び出しがサポートされていなければなりません。 この記事では、FHIR アダプターをインストールした際に自動的に構成されたエンドポイントへの POST 呼び出しを処理する方法を見てみましょう。

FHIR のリソースストレージ呼び出しに関する仕様を確認すると、呼び出しに使用する URL は、以下のフォーマットを使用している必要があります。

http(s)://server_url/{endpoint}/{Resource}

この記事の例では、セキュリティで保護された呼び出しは行わないため、以下のような URL になります。

http://localhost:52774/Adapter/r4/Patient

ここで行いたいのは新しい患者を記録することであるため、呼び出しの本文に患者のデータを含めた POST 呼び出しを行う必要があります。

HealthShare、HealthConnect、および InterSystems IRIS ユーザーが使用できる FHIR アダプターツールに関する連載記事を再開しましょう。

前回の記事では、ワークショップをセットアップした小さなアプリケーションを紹介し、FHIR アダプターをインストールした後に IRIS インスタンスにデプロイされたアーキテクチャを説明しました。 この記事では、最も一般的な CRUD（作成、読み取り、更新、削除）操作の 1 つである読み取り操作を実行する方法の例を確認します。ここではリソースの取得によって行います。

リソースとは？

FHIR のリソースはある種の臨床情報です。この情報は、患者（Patient）、臨床検査へのリクエスト（ServiceRequest）、または診断（Condition）などです。 各リソースはそれを構成するデータのタイプのほか、データの制約や他のリソースタイプとの関係を定義します。 リソースごとに、それが格納する情報の拡張が可能であるため、FHIR ポリシーの範囲外のニーズに 80% 対応できます（ユーザーの 80% が使用する要件に対応）。

この記事の例では、最も一般的なリソースである Patient を使用します。 その定義を確認しましょう。

さて、FHIR アダプターの使用例に戻り、この記事では、IRIS インスタンスでの構成方法とインストールの結果を確認したいと思います。

プロジェクトの構成手順は公式ドキュメントで指示されているものと同じなので、直接こちらで確認できます。 では作業に移りましょう！

インストール

この記事に関連するプロジェクトでわかるように、IRIS インスタンスを Docker でデプロイしています。そのため最初の構成の主な部分は Dockerfile で行います。 Docker 構成については詳しく確認しないため、気にする必要はありません。

FHIR アダプターをインストールする手順は、たったこれだけです。

1. 相互運用性機能を備えた IRIS インスタンスに ADAPTER というネームスペースを作成します。
2. IRIS ターミナルで、そのネームスペースにアクセスして以下のコマンドを実行します。

set status = ##class(HS.FHIRServer.Installer).InteropAdapterConfig("/Adapter/r4")

ここでは、REST リクエストを受信する IRIS エンドポイントの URL を /Adapter/r4 と定義しました。

インストール結果

FHIR アダプターのインストールが完了したら、IRIS インスタンスで何が起きたかを確認できます。

FHIR がシステム間の相互運用性と互換性に関するあらゆる問題に対する万能薬であり、ソリューションであることはご存知のことでしょう。 これは、FHIR リソースを手に掲げてそれに興じる戦士の画像です。

ですが、戦士ではない私たちのために、少しだけ紹介したいと思います。

FHIR とは？

早速定義を述べると、FHIR（Fast Healthcare Interoperability Resource; 高速ヘルスケア相互運用性リソース）とは、ヘルスケア産業において医療データを様々なシステム間で電子的にやり取りできるようにするために、HL7（Health Level 7） 規格化組織が作成した相互運用性の規格です。

FHIR の基盤テクノロジー

REST API や JSON 形式による HTTP 呼び出しの組み合わせを主としています（使用方法に応じて XML やその他の通信も可能）。

FHIR の操作方法

一般に、GET （サーバーからデータを取得）、PUT （データの更新）、POST （データの保存）、および DELETE （削除）などの HTTP 呼び出しを使用して通信する FHIR サーバーを使用するのが最も簡単です。 .

FHIR はサーバーとクライアント間でデータの送受信に使用されるリソースの概念を処理します。

バージョン 2023.3（InterSystems IRIS for Health）の新機能は、FHIR プロファイル基準の検証を実行する機能です。

（*）

この記事では、この機能の基本的な概要を説明します。

FHIR が重要な場合は、この新機能を絶対にお試しになることをお勧めします。このままお読みください。

皆さまこんにちは。
IRIS for Healthを用いてFHIRの開発に携わっている者です。

FHIRリポジトリの導入を検討している方々に向けて、足がかり的な記事になればと思い投稿致します。

<アジェンダ＞
■IISでの環境構築
■POSTMANを利用しないリソースへのデータアクセス
■Patientリソースの作成について
■FHIRリポジトリを使ってみての感想

■おまけEmbedded Pythonを使って、サンプルファイルからFHIRリソースへアクセスする方法

問題

あわただしい臨床環境では迅速な意思決定が重要であるため、文書保管とシステムへのアクセスが合理化されていなければいくつもの障害を生み出します。 文書の保管ソリューションは存在しますが（FHIR など）、それらの文書内で特定の患者データに有意にアクセスして効果的に検索するのは、重大な課題となる可能性があります。

動機

AI により、文書の検索が非常に強力になりました。 Chroma や Langchain のようなオープンソースツールを使用して、ベクトル埋め込みを保存して使用し、生成 AI API 全体でクエリを実行することで、ドキュメント上での質疑応答がかつてないほど簡単になっています。 より献身的に取り組む組織は、既存のドキュメントにインデックスを作成し、エンタープライズ用に微調整されたバージョンの GPT を構築しています。 GPT の現状に関する Andrej Karpathy の講演では、このトピックに関する素晴らしい概要が提供されています。

このプロジェクトは、医療関係者が文書を操作するあらゆるタッチポイントにおいて発生する摩擦を緩和する試みです。 医療関係者が情報を保管し、必要な情報を難なく検索できるように、入力と処理から保管と検索まで、IRIS FHIR と AI を活用しました。

ソリューション

医療関係者が音声メモを記録できるフルスタックのウェブアプリを構築しました。

皆さんこんにちは！

この記事でご紹介する「開発環境テンプレート」は、最近 医療 IT で注目を集めている 医療情報交換標準規格  FHIR を体験できるコンテナです。

一式は、こちら（https://github.com/Intersystems-jp/IRIS-FHIR-Oximeter-Template）で公開しています。

コンテナビルド時、InterSystems IRIS for Health コミュニティエディションを使用した FHIR R4 リソースリポジトリの用意と、REST 用エンドポイントが用意されます。

作成されるエンドポイントに対して、REST クライアントから直接 FHIR R4 リソースリポジトリへアクセスすることもできますし（使用例はこちら／ビデオの解説はこちら）、Patient リソースと Observation リソースの操作体験が行えるサンプル Web アプリケーション（使用例はこちら／ビデオの解説はこちら）もコンテナに含まれていますので、お好みの方法で操作を体験できます。

この開発環境テンプレートでは、さらに！ FHIR  サーバーサイドアプリケーション（＝プロダクション）のサンプルも用意しています（図例はこちら）。

プロダクションは、新生児につけたパルスオキシメーターの測定値が定期的に送信されてくることを仮定して作られています。

FHIRドキュメント（診療情報提供書や退院時サマリ―など）をFHIRリポジトリにPOSTする場合、

エンドポイント/Bundle

上記URLでPOSTできます。（以下の例では、IRIS for Healthに用意したFHIRリポジトリを使用しています。）

GET要求で確認してみます。

登録できたことを確認できました。

FHIRリポジトリに登録したFHIRドキュメントですが、文書番号を指定してGETできると便利なのですが、現時点（バージョン2023.1）のIRIS for HealthのFHIRリポジトリでは、FHIR標準仕様にあるBundle の SearchParameter ：composition について未対応のため、Composition.identifier を指定した Bundleリソースに対する GET要求が行えません。

そこで回避策として、Bundle登録時 Composition.identifier.value に設定している文書番号を Bundle.identifier.value にも設定しPOSTします。こうすることで、Bundle の Search Parameter：identifier に文書番号を指定でき、対象となるBundleリソースをGETできます。

IRIS for HealthのFHIRリポジトリには、「条件付き削除結果の最大数」がデフォルトで3件に設定されています。

そのため、条件指定のDELETE要求で4件以上が対象となる場合、以下のエラーが発生します。

例えば、あるcodeで条件指定したリソースが5件あるとします。

これをDELETE要求に変えて実行すると、以下のようにHTTPステータス412が戻り、「Conditional delete search found more than maximum allowed number of 3 results」のエラーが発生します。

HTTP応答を確認すると、ConditionalDeleteOverflowのエラーが発生しています。

これは、条件付き削除の最大値が3件で設定されているため、発生しています。

ということで、FHIR Configuration画面を開き、設定を確認します。

管理ポータル > [Health] > ネームスペース選択 > [FHIR Configuration] > [Server Configuration]

対象のエンドポイントを選択すると以下の設定画面が表示されます。

Max Conditional Delete Results の項目に 3 と設定されています。

FHIRリソースをリポジトリから削除するには、対象リソースに対してDELETE要求を使用すればよいのですが、例えば「テスト的に登録していたリソースばかりなので、リポジトリのデータを一括で全消去したい！」という場合の方法をご紹介します。

実行前に、エンドポイントのURLを確認します。

管理ポータル > [Health] > ネームスペース選択 > [FHIR Configuration] > [Server Configuration] で確認できます。

データの全消去を行うには、IRIS for HealthのFHIRサーバ機能で提供されているAPIを使用します。実行のため IRISのターミナルを開く、またはIRISにログインします。

ご参考：HS.FHIRServer.Storage.Json.RepoManagerクラスにあるDeleteService()メソッドを使用して削除します。

WindowsにIRISをインストールされている場合は、タスクバー上のIRISランチャー  をクリックし、ターミナルを選択します。

Windows以外でお試しいただいてる場合は、iris session コマンドでIRISにログインしてください。

FHIR関連トレーニングの中で複数の方よりいただいたご質問をご紹介していきます。

IRIS for HealthのFHIRリポジトリでは、リソースPOST時のデフォルトの動作としてリポジトリ内でユニークな論理ID（id）を自動的に付与します。

例えば、以下のようなPatientリソースをPOSTした場合
​

{
    "resourceType": "Patient",
    "address": [
      {
        "postalCode": "1600023",
        "text": "東京都新宿区西新宿6丁目"
      }
    ],
    "birthDate": "1970-01-01",
    "gender": "male",
    "identifier": [
      {
        "value": "P101001"
      }
    ],
    "name": [
      {
        "extension": [
          {
            "url": "http://hl7.

今回は、「IRIS for Health Contest」に応募するために、どのような技術を使ってアプリケーションを開発していたのか、その詳細を紹介したいと思います。

• OpenAPI仕様からのREST API生成
• APIとWebページを保護する役割ベースのアクセス(RBAC)
• InterSystems FHIR サーバー

内容

• アプリケーション概要
• OpenAPI仕様からのREST API生成
• APIとWebページを保護する役割ベースのアクセス(RBAC)
  • REST APIの安全性確保
  • Webページの安全性確保
  • リソースと役割の作成
• InterSystems FHIR サーバー

アプリケーション概要

まず、それらの技術に支えられたアプリケーションを簡単に紹介します。

このアプリケーションは、妊娠中の女性が簡単に症状を報告できるように設計されています。このアプリケーションはレスポンシブであるため、モバイルデバイスを使用して症状を簡単に報告することができます。このような症状は、FHIR Observation リソース のInterSystems FHIR サーバーを使って記録されます。.

患者と医師は、通常のリレーショナル・テーブルを使用し、患者 と 医師 のFHIRリソースのIDを参照して連携しています

FHIR開発者の皆さん、こんにちは！

IRIS の FHIR リポジトリは、HL7 FHIR 標準プロファイルに対する検証をサポートしていますが、カスタムプロファイルに対する検証は、まだサポートできていません（将来のリリースバージョンで対応予定です）。

カスタムプロファイルの Search Parameter の追加はサポートしています！詳しくは、「動画：FHIR プロファイル」をご参照ください。

この記事では、IRIS の FHIR リポジトリに対して、カスタムプロファイルの検証を行う方法についてご紹介します。

方法としては、HL7 FHIR が提供している FHIR Validator で提供しているJARファイル（validator_cli.jar）を利用します。

利用のためには、FHIR リソースの検証のタイミングで、JARファイルの検証を実行するようにFHIRサーバサイドの動作をカスタマイズする必要があります。

ということで、大まかな準備は以下の通りです。

1) Java用外部サーバ（External Language Servers）の開始

IRISから FHIR Validator で提供しているJARファイル（validator_cli.jar）を利用するため、Java用外部サーバを開始します。

Raspberry を FHIRserver として実行する

一年ほど前、
Raspberry Pi での HAPI FHIRserver のインストールに関する記事を書きました。 当時、FHIR 標準の基本しか知らず、FHIR サーバーの背後にあるテクノロジーや Raspberry についてほとんど知りませんした。 試して、失敗して、諦めて、もう一度試すことで、たくさんのことを学びました。

開発者の皆さん、こんにちは。

この記事は、FHIRの関連技術として、FHIRプロファイル作成ツールであるSUSHIの使い方を紹介するシリーズの第2弾です。パート2である今回まで半年の期間が経ってしまいました。

前回のパート1では、FHIRとは？FHIRプロファイルとは？FHIR Shorthandとは？そしてSUSHIとはどのようなツールなのか？どのような物を作成できるのか？について、サンプルの成果物のスクリーンショットを交えながら説明しました。

今回の記事では、SUSHIで作成したプロファイルの実際の活用例として、SUSHIを使ってPatientリソースに Extension を追加し、さらにそのExtensionの項目に対する新しい SearchParameter を定義し、IRIS for HealthのFHIR Repositoyで新しいSearchParameterが使えるようになるまで、をご紹介します。

SUSHIのアップグレード

いきなり本筋とそれて恐縮ですが、SUSHIを久しぶりに触る私のような方はSUSHIのアップグレードを行いましょう。 この半年の間もSUSHIは精力的な機能Enhancementが行われており、8月にはversion 2.0.0がリリースされています。この記事の執筆段階の最新バージョンは SUSHI 2.1.1 でした。

特報！！

この記事の中でご紹介している、FHIRオペレーションのデモを含め、FHIR PathやFHIRプロファイル対応などの2021.1のFHIR関連新機能をご紹介するウェビナーが、2021年10月21日 12:30~13:00 に開催されます！！ご興味ある方はこちらからご登録ください！！

InterSystems IRIS 開発者向けウェビナーシリーズ

開発者の皆さん、こんにちは。 今日は前回のFHIRリポジトリをカスタマイズしよう！パート１の記事に続き、パート2として、カスタムオペレーションの実装方法をご紹介したいと思います。この記事で紹介している内容のFHIRリポジトリカスタムオペレーションに関するドキュメントマニュアルはこちらになります。 この記事はIRIS for Health 2021.1 をベースに記載しています。バージョンによって実装方法が異なるケースも考えられますので、該当のバージョンのドキュメントをご参照ください。場合によっては新しいバージョンへアップグレードもご検討ください。

FHIRのOperation（オペレーション）とは？

まず、FHIRのOperationについて、簡単にご紹介したいと思います。 HL7 FHIR公式ページのOperationのページには以下のように記載されてい

開発者の皆さん、こんにちは。 IRIS for Health 2021.1がリリースされてからしばらくたちますが、多くのユーザさんにFHIRリポジトリ機能をお使いいただいています。 今日はFHIRリポジトリのサーバ側の処理をカスタマイズする機能をご紹介したいと思います。

この記事で紹介している内容のFHIRリポジトリカスタマイズに関するドキュメントマニュアルはこちらになります。

この記事はIRIS for Health 2021.1 をベースに記載しています。バージョンによってはカスタマイズに必要なクラスが異なることがあります（例えば2020.1では後述のRepoManagerクラスはまだありません。）

FHIRサーバカスタマイズの2つのアプローチ

FHIRサーバ機能をカスタマイズするには2つのアプローチがあり、１つはこの記事でご紹介する、Interactionクラス群をカスタマイズしてFHIRリポジトリを拡張する方法、もう一つは、相互運用プロダクションでロジックを実装してサーバとしての動作を変更する方法です。

後者は厳密にはFHIRリポジトリとしての実装はそのままで、リポジトリに受け渡される前、あるいはリポジトリから応答を受けた後に、そのデータを参照、変更してカスタマイズを実装する流れになります。

*この動画は、2021年2月に開催された「InterSystems Japan Virtual Summit 2021」のアーカイブです。

FHIR プラットフォームとして InterSystems IRIS for Health を選択する利点の一つは、クラウド/オンプレミスを含む豊富なプラットフォームの選択肢です。

インターシステムズは新しい選択肢の一つとして、FHIRマネージドサービスである”FHIR Accelerator Service”をまずは米国内でリリースします。このサービスを活用するとユーザはすぐにマネージド環境をプロビジョニングしてFHIRサービス開発／実行環境を入手することができます。
この動画では、AWSクラウド上でホストされるこのサービスについてデモを交えてご紹介しています。

この開発者コミュニティでは他にも IRIS の FHIR 機能に関連した多くの記事を公開しています。 FHIR にご興味ある方はぜひご覧ください。

• FHIR R4 リソースリポジトリを簡単にお試しいただける開発環境テンプレートのご紹介
• Azure 上で IRIS for Health をデプロイし、FHIR リポジトリを構築する方法
• その他FHIR関連記事 (#FHIRタグ)

*この動画は、2021年2月に開催された「InterSystems Japan Virtual Summit 2021」のアーカイブです。

国や地域のニーズに合わせて何のデータをどこにどのように格納するのかを定める共通ルールである FHIR プロファイルは、FHIR による標準化において、非常に重要な要素です。

この動画では、InterSystems IRIS for Health における FHIR リポジトリの構築・設定～ FHIR プロファイルの追加の方法を、最新バージョンおよび今後のバージョンでのサポート内容を含めてご紹介いたします。

この開発者コミュニティでは他にも IRIS の FHIR 機能に関連した多くの記事を公開しています。 FHIR にご興味ある方はぜひご覧ください。

• FHIR R4 リソースリポジトリを簡単にお試しいただける開発環境テンプレートのご紹介
• Azure 上で IRIS for Health をデプロイし、FHIR リポジトリを構築する方法
• その他FHIR関連記事 (#FHIRタグ)

開発者の皆さん、こんにちは。

このシリーズでは、IRIS for Healthの使い方ではなく、関連技術として、FHIRプロファイル作成ツールであるSUSHIの握り方使い方を紹介していきたいと思います。

このツールをうまく使うことで、FHIRプロジェクトのプロファイル情報（仕様や制限、拡張などの情報）をうまく整理し、公開することができます。

その前にSUSHIとは何でしょうか？簡単にですが、順番に説明していきたいと思います。

FHIR って？

FHIRとは Fast Healthcare Interoperability Resources の略であり、Web通信の一般的技術であるRESTを使用して、可読性が高く取り扱いがし易いJSON/XML形式のデータの集合(＝リソース)をやり取りする短期間で実装可能な医療情報交換標準規格、という定義になっています。

簡単に言えば、医療のデータの表現方法として皆で共通したフォーマットを使うことによって、システム間や施設間などでの情報の伝達や交換をやりやすいようにしよう！ということですね。

FHIRには様々なリソースが定義されています。例えば患者さんの情報にはPatientリソースという定義があり、これを使って表現されます。

FHIR公式サイトには多くのサンプルが掲載されていますので、一部抜粋してみます。 例えばこのようなJSON形式で表現されます。

開発者の皆さん、こんにちは。 以前の記事でIRIS for Health上でFHIRリポジトリを構築し、OAuth2認証を構成する方法をご紹介しました。

この代行認証編では、IRIS for HealthのFHIRリポジトリに組み込まれた認証機能ではなく、IRISの代行認証機能＋ZAUTHENTICATEルーチンを使用して認証を行う方法をご紹介します。

前回記事でご紹介したように、標準のFHIRリポジトリの認証機構では、アクセストークンの発行先を追加するためのAudienceの指定(aud=https://~) や、アクセストークンだけではなくベーシック認証の情報を送付するなどの対応が必要でした。

スクラッチでFHIRクライアントを開発するのではなく、既成の製品やアプリケーションからアクセスする場合、上記のような処理の実装ができないことがあるかもしれません。 そのような場合には、この代行認証＋ZAUTHENTICATEルーチンを使用して、カスタマイズした認証の仕組みを構築することができます。

この記事に含まれる情報のドキュメントについて

この記事で記載されている情報はIRIS for Healthのドキュメントにも含まれている内容をわかりやすく再構成したものです。

RESTサービスの保護:RESTアプリケーションおよびOAuth2.0

OAuth 2.