検索

開発者の皆さん、こんにちは！ この投稿では、第8回 InterSystems IRIS Analytics コンテスト の 開発テンプレート（IRIS Analytics Template） の使い方をご紹介します。 開発テンプレートは、Gitからソースコードをダウンロードし、コンテナを開始するだけで Johns Hopkins repository で公開されている COVID-19 のデータを使用した InterSystems BI（旧DeepSee）での分析環境が準備できます（サンプルデータが入ったテーブル、モデル定義、ピボットテーブル、ダッシュボードが準備されます）。 コンテストでは、開発テンプレートをベースとし、コードを追加しながらオリジナルアプリケーションを開発いただいたり、新規で作成いただいたり、自由に開発いただけます。 InterSystems BI を使ったアプリケーションでチャンレンジされる場合は、ぜひ、ここで紹介している開発テンプレートをご利用ください！ この他、サンプルアプリケーションの例は、コンテスト告知ページをご参照ください！ メモ：開発テンプレートはコンテスト以外の目的にもご活用いただけます！ 以下、事前準備についてご説明します。 開発テンプレートをご利用いただくために、以下 3 つのソフトウェアのインストールが必要です。 Docker のインストール（コンテナを管理するアプリ Git のインストール（ソースを管理するアプリ） VSCode のインストール（IDE） 事前準備が整いましたら、開発テンプレートの使い方解説ビデオをご参照ください（ビデオは以下の5本に分かれています。お好みの場所からご参照ください）！ パート1-開発テンプレートに含まれる内容 パート2-サンプルデータ・キューブの概要説明 パート3-新しいデータのインポート（ZPMパッケージマネージャの使い方） パート4-新しいキューブ・ピボット・ダッシュボードの作成とVSCodeへのエクスポート パート5-ダッシュボード以外のUIを使ってみる（DeepSeeWeb） パート1 - 開発テンプレートに含まれる内容について 開発テンプレートのコードは Git に公開されています。 URLをコピーした後、以下実行します。 git clone [コピーしたURL貼り付け] clone で作成されたディレクトリに移動後 docker-compose.yml を利用して、コンテナをビルド＋開始します。 docker-compose up -d コンテナを停止する場合は、以下実行します。 docker-compose stop パート2 - サンプルデータ・キューブの概要説明 サンプルデータは、Johns Hopkins repository　で公開されている COVID-19 のデータを使用しています。 パート2のビデオでは、以下の内容をご紹介しています。 InterSystems BI（旧DeepSee）のキューブサンプル ピボットテーブルサンプル ダッシュボードサンプル 目次 00:00～00:13　　アーキテクト画面の開き方 00:13～02:05　　サンプルデータについて テーブル仕様については、こちらをご参照ください。 02:05～04:02　　アーキテクト画面の使い方 04:02～　　アナライザ画面の使い方（ピボットテーブル作成画面） パート3 - 新しいデータのインポート（ZPMパッケージマネージャの使い方） パート3では、以下の内容をご説明します。 ZPMについて OpenExchange に公開されている ZPM（IRISのパッケージマネージャ）を利用した OpenExchange の公開アプリケーションインポート方法 ZPM対応アプリケーションのインストール方法（csvgen） CSVデータのインポート方法 注意：OpenExchangeに公開されているアプリケーションは、インターシステムズが正式にサポートしているものではありません。 目次 00:00～00:53　　ZPM（パッケージマネージャ）について 00:53～05:27　　csvgen のインポートとCSVのインポート 05:27～　　データの確認 パート4 - 新しいキューブ・ピボット・ダッシュボードの作成とVSCodeへのエクスポート パート4では、以下の内容をご説明します。 インポートした CSV データを利用して、新規でキューブを作成する方法 ピボットテーブルを新規で作成する方法 ダッシュボードを新規で作成する方法 作成した定義を VSCode にエクスポートする方法 目次 00:00～01:35　　キューブの新規作成 01:35～02:55　　ピボットテーブルの作成 02:55～04:59　　ダッシュボードの新規作成＋ウィジェットの追加 04:59～　　VSCode へ作成した定義をエクスポートする方法 パート5 - ダッシュボード以外のUIを使ってみる（DeepSeeWeb） パート5では、OpenExchange に公開されている ZPM（IRISのパッケージマネージャ）を利用し、InterSystems BI が提供しているダッシュボード画面以外のUI（DeepSeeWeb）をインポートする方法をご紹介します。 注意：OpenExchangeに公開されているアプリケーションは、インターシステムズが正式にサポートしているものではありません。 目次 00:00～01:41　　ZPM対応パッケージ：DeepSeeWeb のインストール方法 01:41～　　DeepSeeWeb のUI 確認 以下URLを入力します（ポート番号は環境に合わせて変更してください）http://localhost:ポート番号/dsw/index.html#/IRISAPP/ @Mihoko.Iijima , こんにちは。 素晴らしい記事ですね。とても詳しくてわかりやすいです。 Henriqueさん、ありがとうございます！

この 3 部構成の記事では、IAM を使って、以前に IRIS にデプロイされた認証されていないサービスに OAuth 2.0 標準に従ったセキュリティを追加する方法を説明します。 [パート 1](https://community.intersystems.com/post/securing-your-apis-oauth-20-intersystems-api-management-%E2%80%93-part-1) では、サービスを保護するプロセス全体を理解しやすくするために、IRIS と IAM の基本的な定義と構成を示しながら OAuth 2.0 の背景を説明しました。 このパートでは、着信リクエストに存在するアクセストークンを検証し、検証が成功した場合にはそのリクエストをバックエンドに転送するように IAM を構成する手順について詳しく説明します。 この連載の[最後のパート](https://community.intersystems.com/post/securing-your-apis-oauth-20-intersystems-api-management-%E2%80%93-part-3)では、IAM でアクセストークンを生成し（承認サーバーとして機能します）、それを検証するようにするための構成を説明し、重要な最終考慮事項を示します。 IAM をお試しになりたい方は、InterSystems 営業担当者にお問い合わせください。 シナリオ 1: アクセストークンのバリデーターとして機能する IAM このシナリオでは、JWT（JSON Web トークン）形式でアクセストークンを生成する外部承認サーバーを使用します。 この JWT はアルゴリズム RS256 と秘密鍵を使用して署名されています。 JWT 署名を検証するには、ほかのグループ（この場合 IAM）に承認サーバーが提供する秘密鍵が必要です。 外部承認サーバーが生成するこの JWT には、本体に、このトークンの有効期限を示すタイムスタンプを含む「exp」と呼ばれるクレームと、承認サーバーのアドレスを含む「iss」と呼ばれる別のクレームも含まれます。 したがって、IAM はリクエストを IRIS に転送する前に、承認サーバーの秘密鍵と JWT 内の「exp」クレームに含まれる有効期限のタイムスタンプを使用して、この JWT 署名を検証する必要があります。 これを IAM で構成するために、まず、IAM の「SampleIRISService」に「JWT」というプラグインを追加しましょう。 追加するには、IAM のサービスページに移動して「SampleIRISService」の ID をコピーします。これは後で使用します。 コピーしたら、プラグインに移動して［新規プラグイン］ボタンをクリックし、「JWT」プラグインを見つけて［有効化］をクリックします。 次のページで、［service\_id］フィールドに「SampleIRISService」の ID を貼り付け、［config.claims\_to_verify］パラメーターの「exp」ボックスを選択します。 ［config.key\_claim\_name］パラメーターの値が「iss」であることに注意してください。 これは後で使用します。 次に、［作成］ボタンをクリックします。 クリックしたら、左メニューの「コンシューマー」セクションに移動し、前に作成した「ClientApp」をクリックします。 ［資格情報］タブに移動し、［新しい JWT 資格情報］ボタンをクリックします。 次のページで、JWT の署名に使用されるアルゴリズム（この場合 RS256）を選択肢、［rsa\_public\_key］フィールドに公開鍵（PEM 形式で承認サーバーから提供された公開鍵）を貼り付けます。 ［鍵］フィールドには、JWT プラグインを追加したときに［config.key\_claim\_name］フィールドに入力した JWT クレームのコンテンツを挿入する必要があります。 したがって、この場合は、JWT の iss クレームのコンテンツを挿入する必要があります。私の場合、このコンテンツは承認サーバーのアドレスです。 挿入したら、［作成］ボタンをクリックします。 ヒント: デバッグ用に、JWT をデコードするオンラインツールがあります。それに公開鍵を貼り付けると、クレームとその値を確認して、署名を検証することができます。 このオンラインツールは https://jwt.io/#debugger にあります。 JWT プラグインが追加されたため、認証無しでリクエストを送信することはできなくなりました。 以下に示すように、単純な GET リクエストを認証なしで次の URL に送信する場合、 **http://iamhost:8000/event/1** 「401 Unauthorized」ステータスコードで不正なメッセージが返されます。 IRIS から結果を取得するには、リクエストに JWT を追加する必要があります。 したがって、最初に承認サーバーに JWT をリクエストする必要があります。 ここで使用しているカスタム承認サーバーは、POST リクエストが、ユーザーやクライアント情報を含むキー値ペアとともに次の URL に送信された場合に JWT を返します。 **https://authorizationserver:5001/auth** このリクエストとそのレスポンスは次のようになります。 次に、レスポンスから取得した JWT を承認ヘッダーの下にベアラートークンとして追加し、以前に使用したのと同じ URL に GET リクエストを送信することができます。 **http://iamhost:8000/event/1** または、クエリ文字列パラメーターとして追加することも可能です。クエリ文字列のキーは、JWT プラグインを追加したときに［config.uri\_param\_names］フィールドに指定された値（この場合は「jwt」）です。 最後に、［config.cookie_name］フィールドに名前が入力されている場合は、JWT を cookie としてリクエストに含めるオプションもあります。 IAM でアクセストークンを生成して検証するために必要な構成と重要な最終考慮事項を理解するには、この連載のパート 3 であり最後となる記事をご覧ください。

この 3 部構成の記事では、IAM を使って、以前に IRIS にデプロイされた認証されていないサービスに OAuth 2.0 標準に従ったセキュリティを追加する方法を説明します。 [パート 1](https://community.intersystems.com/post/securing-your-apis-oauth-20-intersystems-api-management-%E2%80%93-part-1) では、サービスを保護するプロセス全体を理解しやすくするために、IRIS と IAM の基本的な定義と構成を示しながら OAuth 2.0 の背景を説明しました。 [パート 2](https://community.intersystems.com/post/securing-your-apis-oauth-20-intersystems-api-management-%E2%80%93-part-2) では、着信リクエストに存在するアクセストークンを検証し、検証が成功した場合にはそのリクエストをバックエンドに転送するように IAM を構成する手順について詳しく説明しました。 連載の最後となるこのパートでは、IAM がアクセストークンを生成（承認サーバーとして機能します）してそれを検証するために必要な構成と、重要な最終考慮事項を説明します。 IAM をお試しになりたい方は、InterSystems 営業担当者にお問い合わせください。 シナリオ 2: 承認サーバーとアクセストークンのバリデーターとしての IAM このシナリオでは、最初のシナリオとは異なり、「OAuth 2.0 Authentication」というプラグインを使用します。 このリソース所有者パスワード資格情報フローで IAM を承認サーバーとして使用するには、クライアントアプリケーションがユーザー名とパスワードを認証する必要があります。 IAM からアクセストークンを取得するリクエストは、認証が成功した場合にのみ行う必要があります。 プラグインを「SampleIRISService」に追加しましょう。 以下のスクリーンショットからわかるように、このプラグインを構成するために入力が必要なフィールドがいくつかあります。 まず、「SampleIRISService」の ID を［service_id］フィールドに貼り付けて、このプラグインをサービスに適用します。 ［config.auth\_header\_name］フィールドには、承認トークンを運搬するヘッダー名を指定します。 ここでは、デフォルト値の「authorization」のままにします。 「OAuth 2.0 Authentication」プラグインは、認可コードグラント、クライアント資格情報、インプリシットグラント、またはリソース所有者パスワード資格情報グラントの OAuth 2.0 フローをサポートしています。 この記事ではリソース所有者パスワードを使用しているため、［config.enable\_password\_grant］チェックボックスをオンにします。 ［config.provision_key］フィールドには、プロビジョンキーとして使用される任意の文字列を入力します。 この値は、IAM にアクセストークンをリクエストするために使用されます。 ここでは、ほかのすべてのフィールドはデフォルト値のままにしました。 各フィールドの完全なリファレンスは、[こちら](https://docs.intersystems.com/iris20193/csp/docbook/apimgr/plugins/oauth2.html)からアクセスできるプラグインのドキュメントをご覧ください。 最終的に、プラグイン構成は次のようになります。 プラグインが作成されたら、「ClientApp」コンシューマーへの資格情報を作成する必要があります。 作成するには、左メニューの［コンシューマー］に移動して［ClientApp］をクリックします。 次に［資格情報］タブをクリックして［新しい OAuth 2.0 アプリケーション］ボタンをクリックします。 次のページでは、［名前］フィールドにアプリケーションを識別するための任意の名前を入力し、［client\_id］フィールドと［client\_secret］にクライアント ID とクライアントシークレットを定義し、［redirect_uri］フィールドに承認後にユーザーが送信されるアプリケーションの URL を入力します。 そして、［作成］をクリックします。 これで、リクエストを送信する準備が整いました。 最初に行うのは、IAM からアクセストークンを取得するためのリクエストです。 「OAuth 2.0 Authentication」プラグインは自動的に、作成済みのルートに「/oauth2/token」パスを追加して、エンドポイントを作成します。 注意: HTTPS プロトコルと、TLS/SSL リクエストをリスンする IAM のプロキシポート（デフォルトポートは 8443）を使用していることを確認してください。 これは OAuth 2.0 の要件です。 したがって、この場合、次の URL に POST リクエストを行う必要があります。 **https://iamhost:8443/event/oauth2/token** リクエスト本文に、次の JSON を含める必要があります。 {    "client_id": "clientid",    "client_secret": "clientsecret",    "grant_type": "password",    "provision_key": "provisionkey",    "authenticated_userid": "1" }   ご覧のとおり、この JSON には「OAuth 2.0 Authentication」プラグイン作成中に定義した値（「grant\_type」や「provision\_key」など）とコンシューマーの資格情報の作成中に定義した値（「client\_id」や「client\_secret」など）が含まれています。 提供されたユーザー名とパスワードが正しく認証された場合には、クライアントアプリケーションによって「authenticated_userid」パラメーターも追加される必要があります。 この値は、認証されたユーザーを一意に識別するために使用されます。 リクエストとそれに対応するレスポンスは次のようになります。   これで、上記のレスポンスの「access_token」値を次の URL への GET リクエストの「ベアラートークン」として含めて、イベントデータを取得するリクエストを行えるようになりました。 **https://iamhost:8443/event/1** アクセストークンが期限切れになった場合は、アクセストークンを取得するために使用したのと同じエンドポイントに、わずかに異なる本文を使って POST リクエストを送信し、期限切れのアクセストークンととも受け取ったリフレッシュトークンを使用して、新しいアクセストークンを生成することができます。 {    "client_id": "clientid",    "client_secret": "clientsecret",    "grant_type": "refresh_token",    "refresh_token": "E50m6Yd9xWy6lybgo3DOvu5ktZTjzkwF" }   リクエストとそれに対応するレスポンスは次のようになります。 「OAuth 2.0 Authentication」プラグインには、アクセストークンを表示して無効にするという興味深い機能があります。 トークンを一覧表示するには、次に示す IAM の管理 API のエンドポイントに GET リクエストを送信します。 **https://iamhost:8444/{workspace\_name}/oauth2\_tokens** 上記の {workspace_name} は使用される IAM ワークスペースの名前です。 RBAC を有効している場合に備え、IAM の管理 API を呼び出すために必要な資格情報を入力してください。 「credential\_id」は ClientApp コンシューマー内に作成した OAuth アプリケーションの ID（この場合は SampleApp）で、「service\_id」はこのプラグインが適用される「SampleIRISService」の ID であることに注意してください。 トークンを無効にするには、次のエンドポイントに DELETE リクエストを送信します。 **https://iamhost:8444/Sample/oauth2\_tokens/{token\_id}** 上記の {token_id} は無効にされるトークンの ID です。 無効化されたトークンを使おうとした場合、この無効なトークンをベアラートークンとして含む GET リクエストを 次の URL に送信すると、トークンが無効であるか期限切れであるというメッセージが表示されます。 **https://iamhost:8443/event/1** 最終的な考慮事項 この記事では、IRIS にデプロイされている認証されていないサービスに対し、IAM で OAuth 2.0 認証を追加する方法を示しました。 サービスそのものは、IRIS で認証されないままとなることに注意してください。 したがって、IRIS サービスのエンドポイントを IAM レイヤーを介さずに直接呼び出すと、情報は認証なしで表示されます。 そのため、ネットワークレベルでセキュリティルールを設定し、不要なリクエストが IAM レイヤーをバイパスしないようにすることが重要です。 IAM の詳細については[こちら](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=AIAM)をご覧ください。 IAM をお試しになりたい方は、InterSystems 営業担当者にお問い合わせください。

InterSystems IRIS for Health, and HealthShare Health Connect のメンテナンスリリースとして2022.1.2 をリリースしました。このリリースは2022.1.0ならびに2022.1.1からの機能追加やバグフィックスを提供します。 変更の詳細については以下のページをご覧ください。 InterSystems IRIS InterSystems IRIS for Health HealthShare Health Connect 製品改善のため、開発者コミュニティを通じてフィードバックをお寄せください。 ソフトウェアの取得方法 ソフトウェアは従来のインストレーションパッケージ形式に加え、コンテナイメージでの提供が可能です。利用可能なインストーラやコンテナイメージの詳細については サポートされるプラットフォームのページをご参照ください。 各種製品の完全なインストレーションパッケージは Software Distribution page をご参照ください。 インストールパッケージとプレビューキーは、WRCのプレビューダウンロードサイトまたは評価サービスのウェブサイト から入手できます。 InterSystems IRIS やIRIS for Healthの製品版やコミュニティエディションのコンテナイメージ、およびそれに対応するすべてのコンポーネントは、以下のコマンドでInterSystems Container Registry から入手できます。 このリリースのビルド番号は2022.1.2.574.0 です。

この度、InterSystems IRIS, InterSystems IRIS for Health, HealthShare Health Connect の追加メンテナンスリリース2021.1.3 を公開しました。 このリリースではこれまでの2021.1.xのリリースよりいくつかの機能やバグフィックスを提供しています。 変更点についての詳細な情報はこれらのページでご覧いただけます。 InterSystems IRIS InterSystems IRIS for Health HealthShare Health Connect より良い製品を一緒に作っていくために開発者コミュニティを通じてご意見をお聞かせください。 ソフトウェアの取得方法 このソフトウェアは、通常のインストールパッケージとコンテナイメージの両方が利用可能です。 利用可能なインストーラーとコンテナイメージの全リストについては、Supported Platforms webpage をご参照ください。 各製品のインストール・パッケージは、WRCのSoftware Distribution page より入手可能です。 コンテナ・イメージは、InterSystems Container Registry から入手できます。 このリリースでは、Community Editionのキットやコンテナは利用できません。 このリリースのビルド番号は 2021.1.3.389.0 です。

Python から InterSystems IRIS へ接続する方法の1つである「PyODBC」(※)の利用方法をご説明します。 ※ Python からのアクセスは、PyODBCの他に、Native API を利用した接続方法もあります。Native APIを利用してIRISのグローバル変数にアクセスする方法については、別の記事でご説明します。 もくじ 最初～0:52　復習ビデオ／関連ビデオについて　（セルフラーニングビデオの索引記事もご参照ください） 0:52～2:04　今回の説明内容解説 2:05～3:44　PyODBCについてと準備 PyODBCのGitHub 3:43～5:25　IRISに接続する 5:25～7:55　CREATE TABLEの実行 7:55～10:16　INSERTの実行 10:16～14:04　SELECTの実行 14:04～最後まで　まとめ ※　YouTubeでご覧いただくと、「もくじ」の秒数クリックでビデオをジャンプできます。 サンプルコード（Git） HelloWorldPyODBC.ipynb 2020年12月7日追記：ODBCドライバ名が古い記述でしたので更新しました。 【修正前】{InterSystems ODBC} 【修正後】{InterSystems IRIS ODBC35} サンプルコード（Git） Thank you so much! It is a great example! It is very useful for me to learn how to use the pyodbc. It's my pleasure I based on your example and made a UI to connect to IRIS forcreate table, upload csv, and make query https://github.com/ecelg/IRIS-SQLCloud-connect-by-pyodbc-with-UI Thanks so much for helping me start my work!

Auth0 と InterSystems IRIS FHIR リポジトリ使った SMART On FHIR に関する連載最終回では、Angular 16 で開発したアプリケーションをレビューします。 このソリューションに定義されたアーキテクチャがどのように構成されているかを思い出しましょう。 フロントエンドのアプリケーションは 2 列目で、ご覧のように 2 つのことを行います。 ログインリクエストを Auth0 にリダイレクトし、レスポンスを受信する。 REST 経由でリクエストを FHIR サーバーに送信し、そのレスポンスを受信する。 Angular Angular は TypeScript が開発し、Google が管理するオープンソースの Web アプリケーションフレームワークで、シングルページ Web アプリケーションの作成と管理に使用されます。 この「シングルページアプリケーション」デザイン手法によって、はるかに動的なユーザー向けアプリケーションを設計することができます。 最初の記事で説明したとおり、ここではアプリケーションサーバーとリバースプロキシとして NGINX を使用し、呼び出しヘッダーがサーバーの呼び出しヘッダーに一致するように変更して、CORS から派生する問題を回避します。 アプリケーションのデザイン モバイルアプリケーションのデザインをシミュレートするように、Angular Material を使ってアプリケーションを設計しました。 この例では、アプリケーションは心拍数、血圧、および体重などの一連の患者データを記録することを目的としており、このために、2 種類の FHIR リソースをサーバーに送信します。1 つ目はユーザーがデータを登録する Patient タイプリソースで、2 つ目は、送信しようとしている各タイプのデータを送信する Observation リソースに対応します。 アプリケーションには、記録されたデータの変化がグラフで表示されます。 ログイン画面 ユーザーがパス https:\\localhost にアクセスすると最初の画面が表示され、そこからログインをリクエストできます。 ログインボタンをクリックすると、アプリケーションは構成済みの API に対して有効化された Auth0 ページに自動的にユーザーをリダイレクトします。 ユーザー名とパスワードを入力すると、Auth0 はデータへのアクセス許可をアプリケーションに付与するよう求めます。 データへのアクセスが確認されたら、Auth0 は、構成プロセス中に指定した URL にリダイレクトします。 アクセストークンが生成されると、Auth0 ライブラリは、サーバーに対して発行するすべての呼び出しのヘッダーにそのトークンを含めるようになります。 これは以下の図で確認できます。 最初の画面 ログインが完了すると、ログインユーザーが使用できる情報を FHIR サーバーにリクエストする最初の通信が発生します。これには、パラメーターによるクエリを使用して、次のような GET 呼び出しを送信します。 https://localhost:8443/smart/fhir/r5/Patient?email=lperezra%40intersystems.com サーバーのレスポンスは次の情報を含む Bundle タイプリソースです。 { "resourceType":"Bundle", "id":"8c5b1efd-cfdd-11ee-a06b-0242ac190002", "type":"searchset", "timestamp":"2024-02-20T10:48:14Z", "total":0, "link":[ { "relation":"self", "url":"https://localhost:8443/smart/fhir/r5/Patient?email=lperezra%40intersystems.com" } ] } ご覧のように、そのメールアドレスを使用する患者は合計 0 人であるため、アプリケーションにはデータを登録できる最初の画面が表示されます。 ご覧のように、メールアドレスのフィールドにはログインユーザーのアドレスが入力されています。これは、最初のクエリで見たように、メールアドレスを ID として使用するためです。 フォームの入力が完了したら、POST 経由で次のような呼び出しを送信します。 https://localhost:8443/smart/fhir/r5/Patient Patient リソースによって形成されたメッセージ本文: { "resourceType":"Patient", "birthDate":"1982-03-08", "gender":"male", "identifier":[ { "type":{ "text":"ID" }, "value":"12345678A" } ], "name":[ { "family":"PÉREZ RAMOS", "given":[ "LUIS ÁNGEL" ] } ], "telecom":[ { "system":"phone", "value":"600102030" }, { "system":"email", "value":"lperezra@intersystems.com" } ] } 患者データがサーバーに登録され、患者のクエリによって結果が返されるようになったため、さまざまな経過観察を記録できる準備が整いました。 最初の画面がどのように表示されるか見てみましょう。 経過観察画面 患者のデータを送信したのと同じ方法で、特定の画面から経過観察を送信します。 サーバーに送信されたリソースごとに、アプリケーションは新しい点をグラフに追加します。 これを行うために、そのユーザーに属する Observation タイプリソースをリクエストするクエリをサーバーに発行します。 https://localhost/smart/fhir/r5/Observation?patient=Patient/1 すると、サーバーはもう一度、その患者に対して記録されたすべての経過観察を含む Bundle タイプリソースを返します。 結果が取得されたので、アプリケーションはすべての数値を抽出し、関連するグラフを構築します。 まとめ この記事と前回の 2 つの記事で確認したように、SMART On FHIR アプリケーションの設計と作成はそれほど複雑ではなく、FHIR サーバーで使用できるすべての機能を利用するアプリケーションを素早くアジャイルに構築することができます。 この種のアプリケーションでは、データに対する CRUD タイプの操作を管理する複雑なバックエンドの開発が不要であり、OAuth2 を使用することで、アプリケーションのユーザーを管理する必要もありません。その機能は Auth0 または選択した認証・承認サーバーに任せることができます。 SMART On FHIR では、簡単かつ単純な方法で、患者と医療専門家に対し医療データ管理に必要なツールを提供することができます。 お読みいただきありがとうございました！

開発者のみなさん、こんにちは！ 2/16-2/18に開催しましたインターシステムズの年次カンファレンス「InterSystems Japan Virtual Summit 2021」のオンデマンド配信を開始しました。3/19（金）までご視聴いただけます。 ⚡️ ご視聴はこちらから ⚡️ テーマは「データプラットフォーム最前線　ニューノーマル時代に求められるアジリティとレジリエンス」です。InterSystems IRIS 、IRIS for Health の最新技術情報を多くのセッションを通してお届け致します。ぜひご視聴ください。*本セミナーは日本語での開催となります。 オンデマンド配信プログラム 基調講演：適応力と柔軟性を高めるデータプラットフォームの最新情報について（2月16日ライブ配信） 先進データテクノロジーセッション：既にインターシステムズ製品をお使いの方向けに、IRISへのマイグレーションやパフォーマンスについての技術セッション（2月17日ライブ配信） HL7® FHIR® によるインターオペラビリティセッション： FHIR の概要や最新情報と、IRIS for Healthでの医療データ共有、最新機能について（2月17日ライブ配信） 先進データテクノロジーセッション ：Python、Kubernetes など、最新技術を活用した IRIS の運用と開発、IntegratedMLなどIRISの最新機能について（2月18日ライブ配信） 英語技術セッション：昨年開催された「InterSystems Virtual Summit 2020」の技術セッションを字幕付きで配信 開催形式：オンライン配信 オンデマンド配信期間：2月19日（金）～3月19日（金） *初めてご覧頂く方は、ご登録をお願いしております。ご登録後に視聴URLをメールでお送りいたします。 参加費：無料 オンデマンド配信はこちらから 数多くの技術コンテンツをお届けしています。ぜひご視聴ください！

これは、InterSystems FAQサイトの記事です。 以下ドキュメントは、IRIS 最新バージョンと Caché/Ensemble2018.1 でサポートしているクラウドプラットフォームの一覧です。 ※Amazon EC2 は、2010.2.0以降でサポートしています。　Microsoft Azureは、2014.1.0以降でサポートしています。　Google クラウドプラットフォームは、IRIS2018.1以降でサポートしています。 IRIS 最新バージョンサポートクラウドプラットフォーム Caché/Ensemble2018.1のサポートクラウドプラットフォーム 他バージョンの対応については、弊社サポートページからバージョン毎の説明ページをご参照ください。 クラウド環境を利用するにあたり、別途ライセンスの追加購入は必要はありません。必要なライセンスは、InterSystems製品が稼働する仮想サーバのOSで必要なライセンス(Windows 64/32bit、Linux 64bit、Core数等に依存)となります。 クラウド上に環境構築するにあたり検討・考慮すべき点として、AWS では、2015.1 より前のバージョンをインストールする場合には制限があります。詳細は関連トピックをご覧ください。 構成については、以下の記事をご覧ください。 Amazon EC2 における InterSystems のテクノロジー: リファレンスアーキテクチャ Microsoft Azure Resource Manager（ARM）向けInterSystemsサンプルリファレンスアーキテクチャ また、アプリケーションや選択される構成によりますが、オンプレミスの場合と比べてパフォーマンスに違いが出る場合があります。パフォーマンスにセンシティブなアプリケーションでは、パフォーマンステストを行うことを推奨します。

開発者の皆さん、こんにちは！ IRIS Cloud SQL and IntegratedML コンテストの勝者が発表されました！ この記事では、コンテスト受賞者を発表します。 今回は、8 の応募 🔥 がありました！ Experts Nomination 🥇 1位 - $5,000 は、 Sheep’s Galaxy を開発された @Maria.Gladkova さん、@KATSIARYNA.Shaustruk さん、 @Maria.Nesterenko さんに贈られました。 🥈 2位 - $3,000 は、 AI text detection を開発された @Oleh.Dontsov さんに贈られました。 🥉 3位 - $1,500 は、 superset-iris を開発された @Dmitry.Maslennikov さんに贈られました。 🏅 4位 - $750 は、 iris-mlm-explainer を開発された @Muhammad.Waseem さんに贈られました。 🏅 5位 - $500 は、 Customer churn predictor を開発された @Oleh.Dontsov さんに贈られました。 More winners: 🏅 $100 は、 audit-consolidator を開発された @Oliver.Wilms さんに贈られました。 🏅 $100 は、 Tokenizator を開発された @Yuri.Gomes さんに贈られました。 🏅 $100 は、 IntegratedML-IRIS-Cloud-Height-prediction を開発された @珊珊.喻 さんに贈られました。 Community Nomination 🥇 1位 - $1,000 は、superset-iris を開発された @Dmitry.Maslennikov さんに贈られました。 🥈 2位 - $750 は、Sheep’s Galaxy を開発された @Maria.Gladkova さん、@KATSIARYNA.Shaustruk さん、 @Maria.Nesterenko さんに贈られました。 🥉 3位 - $500 は、AI text detection を開発された @Oleh.Dontsov さんに贈られました。 今回も、コンテストにご注目いただきありがとうございました！ では、また、次のコンテストをお楽しみに！😎

誰もがテスト環境を持っています。 本番環境とは完全に独立した実行環境を持てるほど幸運な人もいます。 -- 作者不明 この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 Git 101 Gitフロー（開発プロセス） GitLabのインストール GitLabワークフロー GitLab CI/CD CI/CDとコンテナ この最初のパートでは、最新のソフトウェア開発の基礎であるGitバージョン管理システムとさまざまなGitフローを扱います。 Git 101 これから説明する主なトピックでは、後の概念をより良く理解できるようにするため、ソフトウェア開発全般とGitlabがその取り込みにどのように役立っているのか、Git、あるいはもっと厳密に言えば重要なGit設計の基礎となる複数の高度な概念を取り上げます。 そして、Gitは以下のようなアイデア（他にもたくさんありますが、これらが最も重要なアイデアです）に基づいたバージョン管理システムです。 直線的でない開発とは、ソフトウェアが結果的にバージョン1から2、3とリリースされている間に、その裏でバージョン1から2への移行が並行して行われることを指しています。実際、さまざまな開発者が多数の機能/バグ修正を同時に開発しています。 分散開発とは、開発者が単一の中央サーバーや他の開発者から独立している状態を指しており、自分の環境で簡単に開発できます。 マージ - 前の2つのアイデアによって多くの別バージョンが同時に存在することになり、それらを統合して1つの完全な状態に戻す必要性が生じます。 ただ、Gitがこれらの概念を発明したと言っているのではありません。 違います。 むしろGitはこれらの概念を容易化・一般化し、関連する複数のイノベーション（Infrastructure as Code/コンテナ化によるソフトウェア開発の変化など）と結びつけました。 git基本用語集 リポジトリはデータとそのデータに関するメタ情報を保存するプロジェクトです。 物理的にはリポジトリはディスク上のディレクトリです。 リポジトリはファイルとディレクトリを保存します。 リポジトリには各ファイルの変更の完全な履歴も保存されます。 リポジトリは以下の場所に保存できます。 お使いのコンピューター（ローカル） リモートサーバー（リモート） しかし、gitの観点からするとローカルリポジトリとリモートリポジトリには特に違いはありません。 コミットはリポジトリのある決まった状態を表しています。 コミットするたびにリポジトリの完全な状態を保存していては、リポジトリが急速に肥大化してしまうのは明らかです。 そのため、コミットでは現在のコミットとその親コミットとの差分であるdiffを保存しています。 異なるコミットは、次のように異なる数の親を持つことができます。 0 - リポジトリ内の最初のコミットには親がありません。 1 - これは通常の状況です。コミットが親コミットと同じようにリポジトリ内の何かを変更するとこうなります。 2 - 2種類のリポジトリの状態がある場合、それらを1つの新しい状態に統合できます。 また、その状態とそのコミットには2つの親があります。 3以上 - 2種類を超えるリポジトリの状態を1つの新しい状態に統合した場合に発生し得ます。 これは私たちの議論には特に関係ないと思いますが、このような場合もあります。 親の場合、その差分となる各コミットは子コミットと呼ばれます。 各親コミットには、任意の数の子コミットを含めることができます。 ブランチはコミットへの参照（またはポインタ）です。次のようなイメージです。 この画像には2つのコミット（灰色の円）を持つリポジトリがあります。2番目のコミットはmasterブランチのHEADです。 コミットを追加すると、リポジトリは次のようになります。 これは最も単純なケースです。 1人の開発者が同時に1つの変更を手がけます。 しかし、通常は多くの開発者が同時に別々の機能を手がけているため、リポジトリの状況を表示するためのコミットツリーが必要になります。 コミットツリー 同じ出発点から始めましょう。 2つのコミットを含むリポジトリを次に示します。 ただし、今度は2人の開発者が同時に作業しており、互いに干渉しないように別々のブランチで作業しています。 この二人はしばらく経ってからブランチへの変更内容を統合する必要があり、そのためにマージリクエスト（プルリクエストとも呼ばれています）を作成します。これはまさに文字通り2つの異なるリポジトリの状態を1つの新しい状態に統合する（この場合はdevelopブランチをmasterブランチに統合する）ためのリクエストです。 適切なレビューと承認が行われた後、リポジトリは次のようになります。 その後も開発は継続されます。 Git 101 - 概要 主な概念： Gitは直線的でない分散バージョン管理システムです。 リポジトリはデータとそのデータに関するメタ情報を保存します。 コミットはリポジトリのある決まった状態を表しています。 ブランチはコミットへの参照です。 マージリクエスト（プルリクエストとも呼ばれています）は、2つの異なるリポジトリの状態を1つの新しい状態に統合するためのリクエストです。 Gitについてさらに詳しく知りたい場合は、こちらから書籍を入手できます。 Gitフロー Gitの基本的な用語と概念は理解していただけたかと思いますので、今度はGitを使用してソフトウェアライフサイクルの開発部分を管理する方法について説明しましょう。Gitを使用した開発プロセスを説明する多くのプラクティス（フローと呼ばれる）がありますが、ここではそのうち以下の2つについて説明します。 GitHubフロー GitLabフロー GitHubフロー GitHubフローは簡単です。 以下のとおりです。 リポジトリからブランチを作成します。 自分の変更を新しいブランチにコミットします。 自分が提案した変更を含むブランチからプルリクエストを送信して、ディスカッションを開始します。 必要に応じてブランチでさらに変更をコミットします。 プルリクエストは自動的に更新されます。 ブランチをマージする準備ができたら、プルリクエストをマージします。 また、以下のようないくつかのルールに従う必要があります。 masterブランチが常にデプロイ可能であること（また、機能すること！） masterブランチで直接開発が行われていないこと フィーチャーブランチで開発が進行中であること master はプロダクション（Production）* 環境** であること できるだけ頻繁に本番環境にデプロイすること * 「Ensemble Productions」と混同しないでください。ここでは、「Production」とは本番を意味します。 ** 環境とは、コードが実行される構成済みの場所です。サーバー、VM、コンテナなどが考えられます。 以下にそのイメージを掲載します。 GitHubフローの詳細については、こちらで確認できます。 また、図解ガイドもあります。 Gitフローを使い始めるのであれば、GitHubフローを小規模なプロジェクトで試すのが最適です。 GitHubもこれを使用していますが、大規模なプロジェクトでも実行可能です。 GitLabフロー 本番環境にすぐにデプロイする準備ができていない場合、GitLabフローはGitHubフローと環境を提供します。 ここではその動作を説明します。上記と同じフィーチャーブランチで開発し、上記と同じマスターにマージするとしましょう。しかし、その場合はmasterはテスト環境にのみ等しくなるという点が異なります。 また、さまざまな他の環境にリンクされている「環境ブランチ」が存在する場合もあります。 通常、以下の3つの環境が存在します（必要に応じてさらに作成できます）。 テスト環境 == masterブランチ プリプロダクション環境 == preprodブランチ プロダクション環境 == prodブランチ いずれかの環境ブランチに届いたコードは、対応する環境にすぐに移動する必要があります。以下のいずれかで実行できます。 自動（パート2およびパート3で対応します） 半自動（デプロイを許可するボタンを押すこと以外は自動と同じ） 手動 プロセス全体は次のようになります。 機能はフィーチャーブランチで開発されます。 フィーチャーブランチがレビューされ、masterブランチにマージされます。 しばらくすると（いくつかのフィーチャーブランチがマージされた）マスターがpreprodにマージされます。 しばらくすると（ユーザーテストなどの後に）preprodがprodにマージされます。  マージおよびテスト中にいくつかの新機能が開発され、マスターにマージされます。そして3に戻ります。 これは次のようになります。 GitLabフローの詳細については、こちらで確認できます。 まとめ Gitは直線的でない分散バージョン管理システムです。 Gitフローはソフトウェア開発サイクルのガイドラインとして使用できます。また、その中にはいくつかの選択肢があります。 リンク Gitの書籍 GitHubフロー GitLabフロー Driessenフロー（より包括的なフロー、比較用） この記事のコード ディスカッションの質問 gitフローを使用していますか？ どのフローですか？ 平均的なプロジェクトにはいくつの環境がありますか？ 次の内容 次のパートの実施内容： GitLabをインストールします。 いくつかの推奨される調整事項を紹介します。 GitLabワークフローについて議論します（GitLabフローと混同しないこと）。 ご期待ください。

IRISから他DDLのデータを参照したり取り込んだりする場合、各DDLのデータ型はそれと同等の InterSystems IRIS データ型にマッピングされます。 マッピングの定義は、管理ポータル、および、下記ドキュメントページでご確認いただけます。 管理ポータル：[システム管理] > [構成] > [SQLとオブジェクトの設定] > [システムDDLマッピング] ドキュメント：InterSystems IRIS へのデータ型のマッピングの表示

更新: 開発者プレビュー・リリース3が公開されました これはインターシステムズにとって初めての開発者プレビュー・リリースであるため、これらがどのようなものであるかを説明します。 開発者プレビュー・プログラムは、従来のIRISプレビュー・プログラムを強化したもので、約2週間ごとにリリースされ、準備が整うと機能が追加されます。 これにより、機能や機能拡張に関するフィードバックを得ることができます。 2022.1に向けた機能拡張のリストは以下の通りです。これらは最初の開発者プレビューには含まれていません。 これらは今後数週間のうちに公開される予定です。 一般公開に先立ち、皆様からのご意見をお待ちしています。より良い製品を一緒に作っていくために、開発者コミュニティを通じてフィードバックを共有してください。 InterSystems IRIS Data Platform 2022.1 は、エクステンデッド・メンテナンス (EM) リリースです。2022.1 には、前回の EM リリースである 2021.1 以降、継続的デリバリー (CD) リリースである 2021.2 で追加された多くの重要な新機能や拡張機能が追加されています。これらの機能強化の概要については、2021.2 のリリース・ノートをご参照ください。InterSystems IRIS Data Platform 2022.1 の新機能として、本番用と開発用プラットフォームの両方で、新たにサポートが拡張されます。 InterSystems IRIS は、以下をサポートします (注: これらの拡張機能は、開発者プレビュー 1 には含まれていません)。 Windows Server 2022 Windows 11 AIX 7.3 Oracle Linux 8 さらに、開発環境向けにApple社のM1チップセットのサポートが追加されました。MacOS Monterey（12）のサポートは2022.1のリリースで予定されていますが、開発者プレビュー1には含まれていません その他の重要な強化点は以下の通りです。 System Alerting & Monitoring (SAM)のスピードとスケールの改善 IRIS .NET SDK が .NET 5 をサポートしました。 InterSystems Reports の改良 顧客のInteroperabilityコンポーネントを容易に再利用できるようにするProduction Extensions (PEX)の使いやすさの向上 これらの機能の詳細については、製品のドキュメントを参照してください InterSystems IRIS 2022.1 ドキュメント and リリースノート InterSystems IRIS for Health 2022.1 ドキュメント and リリース・ノート HealthShare Health Connect 2022.1 ドキュメント and リリース・ノート EMのリリースには、サポートされているすべてのプラットフォーム用のクラシックなインストール・パッケージと、OCI (Open Container Initiative)、別名Dockerコンテナ形式のコンテナ・イメージが付属しています。 完全なリストについては、サポートされるプラットフォームのドキュメントを参照してください。 インストールパッケージとプレビューキーは、WRCのプレビューダウンロードサイトから入手できます。 InterSystems IRISおよびIRIS for HealthのEnterprise Editionと対応するすべてのコンポーネントのコンテナ・イメージは、以下のコマンドを使用してInterSystems Container Registryから入手できます。 docker pull containers.intersystems.com/intersystems/iris:2022.1.0.114.0 docker pull containers.intersystems.com/intersystems/irishealth:2022.1.0.114.0 docker pull containers.intersystems.com/intersystems/iris-arm64:2022.1.0.114.0 docker pull containers.intersystems.com/intersystems/irishealth-arm64:2022.1.0.114.0 利用可能なイメージの一覧については、ICRのドキュメントを参照してください。 Community Edition のコンテナ・イメージは、以下のコマンドで InterSystems Container Registry から取得することも可能です。 docker pull containers.intersystems.com/intersystems/iris-community:2022.1.0.114.0 docker pull containers.intersystems.com/intersystems/irishealth-community:2022.1.0.114.0 docker pull containers.intersystems.com/intersystems/iris-community-arm64:2022.1.0.114.0 docker pull containers.intersystems.com/intersystems/irishealth-community-arm64:2022.1.0.114.0 また、WRC のプレビュー・ダウンロード・サイトから、すべてのコンテナ・イメージの tar形式版を入手することもできます。 InterSystems IRIS Studio 2022.1 は、Microsoft Windows で使用するスタンドアロンの IDE で、WRC のプレビュー・ダウンロード・サイトからダウンロードできます。インターシステムズ社のIRISおよびIRIS for Healthのバージョン2022.1以下で動作します。また、InterSystems IRIS 用のアプリケーションを Visual Studio Code で開発するための VSCode-ObjectScript プラグインもサポートしており、Microsoft Windows、Linux、MacOS で利用可能です。 この開発者プレビュー・リリースのビルド番号は、2022.1.0.114.0 です。

開発者のみなさん、こんにちは！ 2022年3月9日開催「InterSystems Japan Virtual Summit 2022」のセッション「Embedded Python で広がる InterSystems IRIS の世界」のアーカイブを YouTube に公開いたしました。 （プレイリストはこちら） 今や Python は最も人気のあるプログラミング言語の一つです。シンプルで機能的なコードが書けることや、なんでも揃う豊富なライブラリを利用できることなどが人気の理由です。 Embedded Python は、IRIS に Python のランタイムを組み込み、ルーチンやメソッドを Python で書けるようにする画期的な機能です。 IRIS 開発者の方にとって、広大な Python の世界が身近になります。InterSystems IRIS の新しいカタチを是非ご覧ください。 【目次】 00:52 Python とは何か？ 04:20 Embedded Python とは何か？ 06:29 使用パターン 08:15 活用シナリオ 12:20 デモ1：Jupyter Notebook を使って IRIS からデータを取得して分析 22:00 デモ2：IRIS プログラムから Python を利用する

これは、2022.2の開発者プレビュープログラムのリリース第3弾です。 プレビューリリースは、隔週で更新される予定で、準備が整い次第、機能を追加していく予定です。 2022.2では、SQL管理、クラウド統合、KafkaおよびJMSアダプタ、SQL Loaderなどにおいて、多くのアップデート、修正、機能強化が行われています。 製品改善のため、開発者コミュニティを通じてフィードバックをお寄せください 列指向ストレージに関して、Early Access Program (EAP) を受け付けています。ご興味のある方はぜひ Early Access Program にご参加ください。 CDリリースには、サポートされているすべてのプラットフォーム向けの標準インストールパッケージと、OCI（Open Container Initiative、別名Dockerコンテナ）形式のコンテナイメージが付属しています。 詳細については、サポートされるプラットフォームのドキュメントをご参照ください。 インストールパッケージとプレビューキーは、WRCのプレビューダウンロードサイトまたは評価サービスのウェブサイト（2022.2へのアクセスには「Show Preview Software」をチェックしてください）から入手できます。 InterSystems IRIS やIRIS for Healthの製品版コンテナイメージ、およびそれに対応するすべてのコンポーネントは、以下のコマンドでInterSystems Container Registry から入手できます。 docker pull containers.intersystems.com/intersystems/iris:2022.2.0.293.0 docker pull containers.intersystems.com/intersystems/irishealth:2022.2.0.293.0 docker pull containers.intersystems.com/intersystems/iris-arm64:2022.2.0.293.0 docker pull containers.intersystems.com/intersystems/irishealth-arm64:2022.2.0.293.0 コミュニティエディションのコンテナイメージも以下のコマンドで InterSystems Container Registry から入手できます。 docker pull containers.intersystems.com/intersystems/iris-community:2022.2.0.293.0 docker pull containers.intersystems.com/intersystems/irishealth-community:2022.2.0.293.0 docker pull containers.intersystems.com/intersystems/iris-community-arm64:2022.2.0.293.0 docker pull containers.intersystems.com/intersystems/irishealth-community-arm64:2022.2.0.293.0 利用可能なイメージの詳細については、ICRのドキュメントを参照してください。 また、すべてのコンテナイメージのtarballバージョンは、WRCのプレビューダウンロードサイトから入手できます。 ※ WRCへのアクセスにはWRCアカウントが必要です。 開発者向けプレビューリリースのビルド番号は2022.2.0.293.0 です。 次の更新は２週間後です！