これは、InterSystems FAQサイトの記事です。
HL7の仕様では、日本語データを送受信する場合はJISを文字コードとして利用し、メッセージヘッダ（MSH）の18番目の2項目に iso-ir87 を指定します。
HL7用プロダクションでは、情報の入力はビジネスサービス、情報の出力はビジネスオペレーションを利用します。
日本語を含むHL7を送受信する場合は、入力／出力の対象となる全てのコンポーネントの設定で [追加の設定] の「キャラクターセット（Charset）」に iso-ir87 を指定することで正しく日本語データを取り扱うことができます。
InterSystemsは最近、HL7バージョン2の相互運用性に焦点を当てた、IRIS for Health 2020.1のパフォーマンスとスケーラビリティのベンチマークを完了しました。 この記事では、さまざまなワークロードで観察されたスループットを説明し、IRIS for HealthをHL7v2メッセージングの相互運用性エンジンとして使用しているシステムの一般的な構成とサイジングのガイドラインを提供します。
ベンチマークは本番環境にほぼ一致するように設計されたワークロードをシミュレーションしています。 シミュレーションの詳細は、「ワークロードの説明と方法」セクションで説明しています。 テストされたワークロードは、HL7v2 Patient Administration（ADT）とObservation Result（ORU）ペイロードで構成され、変換と再ルーティングが含まれました。IRIS for Healthの2020.1バージョンは、第2世代のIntel® Xeon® スケーラブルプロセッサとIntel® Optane™ SSD DC P4800XシリーズSSDストレージを使用したコモディティサーバーで、1日当たり23億件を超えるメッセージ（インバウンドとアウトバウンドの合計）スループットの持続を実証しました。 これらの結果は、以前のEnsemble 2017.1 HL7v2スループットベンチマークのスケーラビリティの2倍以上です。
これらのテストでは、IRIS for Healthは、先入先出（FIFO）の順序を保持し、インバウンドメッセージとアウトバウンドメッセージのメッセージとキューを完全に永続化するように構成されました。 キューとメッセージを永続化することで、IRIS for Healthはシステムがクラッシュした際に、データ保護と、履歴メッセージの完全な検索と再送機能を提供することがでます。
さらに、構成ガイドラインは以下のセクションで説明されており、ワークロードのパフォーマンスとスケーラビリティの要件を適切に満たす構成とデプロイを選択する上で役立てられます。
この結果は、IRIS for Healthがコモディティハードウェアで極端なメッセージングスループットを満たすことができ、ほとんどの場合において、1つの小さなサーバーで組織全体にHL7の相互運用性を提供できることを示しています。
HL7相互運用性アクティビティのさまざまな側面を表すために、次の3つのワークロードが使用されました。
上記の3つのワークロードは、Red Hat Enterprise Linux 8を実行する2つの750GB 2つのIntel® Optane™ SSD DC P4800X SSDドライブとIntel® Scalable Gold 6252プロセッサを備えた物理48コアシステムで実行されました。 データは、1秒当たり（および1時間当たり）のインバウンドごとのメッセージ数、1秒当たりの（および1時間当たり）のアウトバウンドごとのメッセージ数、および1日10時間のメッセージ合計数（インバウンドとアウトバウンド）で表示されています。 また、特定のレベルのスループットにおいて利用可能なシステムリソースの測定値として、CPU使用率が表示されています。
表1: このテスト済みのハードウェア構成における4つのワークロードのスループットの要約:
* 25%のT1/ 25%のT2 / 50%のT4ワークロードの比率で組み合わされたワークロード
テストされたワークロードには、HL7v2 Patient Administration（ADT）とObservation Result（ORU）メッセージが含まれ、平均1.2 KBのサイズと平均14のセグメントが含まれました。 変換によっておよそ4つのセグメントが変更されました（T2およびT4ワークロード）。 テストは、TCP/IPを介してメッセージを送受信する48件から128件のインバウンドと48件から128件のアウトバウンドのインターフェースを表します。
T1ワークロードでは、それぞれに16個のインターフェースを持つ4つの個別のネームスペースが使用され、T2ワークロードでは、それぞれに16個のインターフェースを持つ3つのネームスペースが使用され、T4ワークロードでは、それぞれに32個のインターフェースを持つ4つのネームスペースが使用され、最後の「混合ワークロード」では、T1ワークロードに16個、T2ワークロードに16個、T4ワークロードに32個を持つ3つのネームスペースが使用されました。
スケーラビリティは、各インターフェースのトラフィックを徐々に増やして許容可能なパフォーマンス基準で最高のスループットを見つけることで測定されました。 許容可能なパフォーマンスを得るには、メッセージがキューイングやメッセージの配信に測定可能な遅延のない持続的な速度で処理され、平均CPU使用率が80%未満である必要があります。
以前のテストでは、使用されたHL7メッセージのタイプはEnsembleのパフォーマンスやスケーラビリティにとって重要ではありませんでしたが、インバウンドメッセージ数、インバウンドとアウトバウンドメッセージのサイズ、ルーティングエンジンで作成される新しいメッセージの数、および変更されたセグメント数が重要でした。
さらに、以前のテストでは、データ変換でHL7メッセージの個別のフィールドを処理することは、通常、パフォーマンスに影響がないことが示されています。 これらテストの変換では、かなり単純な割り当てを使用して、新しいメッセージが作成されています。 複雑な処理（データ変換での広範なSQLクエリの使用など）によって、結果が異なる場合があることに注意してください。
以前のテストではまた、ルール処理は通常重要でないことも確認されています。 これらのテストで使用されたルーティングルールセットは平均32個のルールで、すべてのルールは単純です。 ルールセットが極端に大きいか複雑な場合は、結果が異なる場合があります。
テストでは、2.1 GHzの48コアの2ソケットシステムで、192 GB DDR4-2933 DRAMと10 Gb Ethernetネットワークインターフェースを使用するソケットごとに24コアを提供する第2世代Intel® Scalable Gold 6252「Cascade Lake」プロセッサを搭載したサーバーが使用されました。 このテストでは、Red Hat Enterprise Linux Server 8オペレーティングシステムでInterSystems IRIS for Health 2020.1を使用しました。
IRIS for Healthを通過するメッセージは、ディスクに完全に永続されます。 このテストの場合、システム内部の2つのIntel 750GB Intel® Optane™ SSD DC P4800X SSDドライブを使用して、片方をデータベース用、もう片方をジャーナル用として分割しました。 さらに、実際の比較を実現できるにように、ジャーナルの同期コミットを有効にして、データの耐久性を強化しています。 前述のT4ワークロードの場合、各インバウンドHL7メッセージはおよそ50 KBのデータを生成しますが、これを表2に説明するように分類できます。 トランザクションジャーナルは通常、メッセージデータやログよりも短い時間オンラインに保持されるため、必要な合計ディスク容量を計算する際に、このことを考慮する必要があります。
表2: インバウンドHL7 T4メッセージあたりのディスク要件
| 項目 | データ要件 |
|---|---|
| セグメントデータ | 4.5 KB |
| HL7メッセージオブジェクト | 2 KB |
| メッセージヘッダー | 1.0 KB |
| ルーティングルールログ | 0.5 KB |
| トランザクションジャーナル | 42 KB |
| 合計 | 50 KB |
T4ワークロードはルーティングエンジンを使用して、個別に変換されたメッセージをそれぞれ4つのアウトバウンドインターフェースにルーティングすることを思い出しましょう。 平均して、インバウンドメッセージの4つのセグメントが変換ごとに変更されました（4 つの変換で1件のインバウンドから4件のアウトバウンド）。 各インバウンドメッセージでは、4 つのデータ変換の実行により 4 つのメッセージがアウトバウンドに送信され、5 つの HL7 メッセージオブジェクトがデータベースに作成されました。
本番環境で使用するシステムを構成する場合、HL7メッセージの1日あたりのインバンドボリュームとパージスケジュール、およびジャーナルファイルの保持ポリシーを考慮して、正味要件を計算する必要があります。 また、適切なジャーナルファイルの容量は、ジャーナルディスクボリュームがいっぱいになるのを防ぐようにして構成する必要があります。 ジャーナルファイルは、パフォーマンスと信頼性を考慮して、データベースファイルから物理的に離れたディスクに存在する必要があります。
これらのテストで示されたInterSystems IRIS for Health HL7v2メッセージスループットは、適度な2ソケットコモディティサーバー構成での大規模なスループット性能によって、組織における要求の最も厳しいメッセージワークロードをサポートできることを示しています。 また、InterSystemsは、最新のサーバーとクラウドテクノロジーを活用しながら、バージョンごとにパフォーマンスとスケーラビリティを改善することに絶えず取り組んでいます。
以下のグラフでは、スループットの増加について、Intel® E5-2600 v3（Haswell）を使用したEnsemble 2015.1とEnsemble 2017.1のベンチマークと第1世代Intel® Scalable Platinum Series（Skylake）プロセッサを使用したEnsemble 2017.1のベンチマークをそれぞれ第2世代Intel® Scalable Gold Series（Cascade Lake）プロセッサでIRIS for Health 2020.1を実行した場合の最新の結果と比較しています。
グラフ1: 単一サーバーでの1日10時間当たりのメッセージスループット（百万単位）。
InterSystems IRIS for Healthは、バージョンが上がるたびに、接続機能の柔軟性を提供するとともに、相互運用性スループットの水準を引き上げ続けています。 上記のグラフからわかるように、メッセージスループットは大きく増加しており、同じ10時間の期間と、23億件以上という24時間の合計メッセージ速度を維持したまま、T2ワークロードの場合には2017の2倍、2015と比較すると3倍以上に増加しています。
IRIS for Healthの進歩を示すもう1つの重要な指標は、T1ワークロードの純粋なパススルー操作とは対照に、変換とルーティングルーツが組み込まれたより複雑なT2とT4ワークロードでのスループットの向上です。
InterSystemsでは、企業や組織におけるインターオペラビリティ（相互運用性）のニーズに対するソリューションのご相談をお待ちしております。
InterSystems および Intel は先日、InterSystems IRIS を「Cascade Late」としても知られる第 2 世代 Intel® Xeon® スケーラブルプロセッサおよび Intel® Optane™ DC パーシステントメモリ（DCPMM）と組み合わせて一連のベンチマークを実施しました。 さまざまなワークロード設定とサーバー構成で、Intel の最新のサーバーテクノロジーを使用した InterSystems IRIS のパフォーマンスとスケーラビリティ機能を実証するのがこのベンチマークの目的です。 このレポートには、さまざまなベンチマークの結果とともに、Intel DCPMM と InterSystems IRIS のユースケースが 3 つ示されています。
パフォーマンスとスケーリングを実証するために 2 種類のワークロードが使用されています。読み取り集中型のワークロードと書き込み集中型のワークロードです。 このように分けて実証するのは、読み取り集中型ワークロードにおけるデータベースキャッシュ効率の増加と、書き込み集中型ワークロードにおけるトランザクションジャーナルの書き込みスループットの増加のそれぞれに特化したユースケースで、Intel DCPMM の影響を示すためです。 両方のユースケースシナリオにおいて、InterSystems IRIS のスループット、スケーラビリティ、およびパフォーマンスの大幅なゲインが達成されています。
読み取り集中型ワークロードでは、4 ソケットサーバーと、合計約 1.2 TB のデータを持つデータセットを使用する大量の長期実行分析クエリが使用されました。 DCPMM を「Memory Mode」で使用した場合のベンチマーク比較では、メモリの少ない前世代の Intel E7v4 シリーズプロセッサと比べた場合、経過実行時間が大幅に短縮され、およそ 6 倍高速になりました。 E7v4 と、DCPMM を使った最新のサーバーを同じメモリサイズで比較した場合は、20% の改善が見られました。 これは、DCPMM による InterSystems IRIS データベースキャッシュ機能の向上と最新の Intel プロセッサアーキテクチャによるものです。
書き込み集中型ワークロードでは、2 ソケットサーバーと InterSystems HL7 メッセージングのベンチマークが使用されました。多数のインバウンドインターフェースで構成されており、各メッセージには複数の変換が伴い、インバウンドメッセージごとに 4 つのアウトバウンドメッセージが使用されています。 高スループットを維持する上で重要なコンポーネントの 1 つは、IRIS for Health のメッセージ耐久性保証で、その操作においては、トランザクションのジャーナル書き込みのパフォーマンスが重要となります。 「APP DIRECT」モードで DCPMM を使用して、DAX XFS でトランザクションのジャーナル用の XFS ファイルシステムを提供した場合、このベンチマークのメッセージスループットには 60% の向上が示されました。
テスト結果と構成を要約すると、DCPMM は適切に設定された InterSystems IRIS とワークロードで使用された場合にスループットを大幅に向上させることができます。 高レベルのメリットとしては、読み取り集中型ワークロードではデータベースのキャッシュ効率の向上とディスク I/O ブロック読み取りの抑制、書き込み集中型ワークロードではジャーナルの書き込みスループットの向上を得られます。
さらに、古いハードウェアを更新し、パフォーマンスとスケーリングの改善を検討しているユーザーにとって、DCPMM を備えた Cascade Lake に基づくサーバーは優れた更新パスとなります。 InterSystems のテクノロジーアーキテクトと相談しながら、既存のワークロードに推奨される構成についてのアドバイスを得ることができます。
読み取り集中型ワークロードでは、512 GiB と 2 TiB のデータベースキャッシュサイズの E7v4（Broadwell）と Intel® Optane™ DC パーシステントメモリ（DCPMM）を使用した 1 TB と 2 TB のデータベースキャッシュサイズの最新の第 2 世代 Intel® Xeon® スケーラブルプロセッサ（Cascade Lake）と比較する分析クエリベンチマークを使用しました。
より大規模なキャッシュの影響とパフォーマンスの向上を示すために、さまざまなグローバルバッファサイズで複数のワークロードを実行しました。 構成を反復するごとに、COLD と WARM で実行しています。 COLD は、データベースキャッシュにデータが事前に入力されていない場合で、 WARM は、データベースキャッシュがすでにアクティブになっており、ディスクからの物理的な読み取りを減らすために、データが入力済みである（または少なくと可能な限り入力されている）ことを示します。
古い 4 ソケット E7v4（Broadwell）ホストを DCPMM を使った 4 ソケット Cascade Lake サーバーと比較しました。 この比較が選択されたのは、InterSystems IRIS を使ってハードウェアの更新を検討している既存のお客様がパフォーマンスの向上を得られることを実証するためです。 バージョン間のソフトウェアの最適化が要因とならないように、すべてのテストには同じバージョンの InterSystems IRIS が使用されました。
ディスクパフォーマンスが比較の要因とならないように、すべてのサーバーには同一のストレージアレイにある同一のストレージが使用されています。 ワーキングセットは 1.2 TB のデータベースです。 図 1 にはこのハードウェア構成と、それぞれの 4 ソケット構成の比較が示されています。
図 1: ハードウェア構成
| サーバー #1 の構成 | サーバー #2 の構成 |
|---|---|
| プロセッサ: 4 x E7-8890 v4 @ 2.5Ghz | プロセッサ: 4 x Platinum 8280L @ 2.6Ghz |
| メモリ: 2TiB DRAM | メモリ: 3TiB DCPMM + 768GiB DRAM |
| ストレージ: 16Gbps FC all-flash SAN @ 2TiB | ストレージ: 16Gbps FC all-flash SAN @ TiB |
| DCPMM: Memory Mode のみ |
512 GiB を 1 TiB か 2 TiB のいずれかの DCPMM バッファプールサイズと比較した場合、経過実行時間に大幅な短縮が見られます（約 6 分の 1）。 さらに、2 TiB E7v4 DRAM と 2 TiB Cascade Lake DCPMM の構成を比較した場合には約 20% の改善も見られました。 バッファプールのサイズが同じであるとした場合、この 20% の増加は、ほぼ新しいプロセッサのアーキテクチャとプロセッサのコア数の増加によるものだと考えられますが、 それでも、テストされた 4 ソケット Cascade Lake にインストールされていたが 24 x 128 GiB DCPMM のみであることを考慮すると深い意義があります。DCPMM は 12 TiB までスケーリングすることが可能であり、これは E7v4 が同じ 4 ソケットサーバーのフットプリントでサポートできるメモリの約 4 倍のメモリです。
以下の図 2 に示されるグラフは、この比較の結果を示しています。 両方のグラフの y 軸は経過時間（値が小さくなるほど良）で、さまざまな構成で得た結果が比較されています。
このベンチマークのワークロードは、すべての T4 タイプのワークロードを使用した HL7v2 メッセージングワークロードです。
各システムは 128 個のインバウンドビジネスサービスと各インバウンドインターフェースに送信される 4800 件のメッセージ（インバウンドメッセージ合計 614,400 件、アウトバウンドメッセージ合計 2,457,600 件）で構成されています。
このベンチマークワークロードのスループットの単位は「1秒あたりのメッセージ数」です。 トランザクションジャーナルのスループットとレイテンシは高スループットを維持する上で重要なコンポーネントであるため、ベンチマーク実行中のジャーナルの書き込みにも関心があります（記録されています）。 IRIS for Health のメッセージ耐久性保証のパフォーマンスに直接影響を与えるため、その操作において、トランザクションジャーナルの書き込みパフォーマンスが重要となります。 ジャーナルのスループットが低下すると、アプリケーションプロセスによってジャーナルバッファの可用性が阻止されてしまいます。
書き込み集中型ワークロードでは、2 ソケットサーバーを使用することにしました。 192 GB の DRAM と 1.5 TiB の DCPMM しかないため、この構成は前述の 4 ソケット構成よりも小さくなります。 DCPMM を使用した Cascade Lake のワークロードを以前の初代 Intel® Xeon® スケーラブルプロセッサ（Skylake）サーバーに比較しました。 両サーバーには 750GiB Intel® Optane™ SSD DC P4800X ドライブがローカル接続されています。
図 3 にはこのハードウェア構成と、それぞれの 2 ソケット構成の比較が示されています。
図 3: 書き込み集中型ワークロードのハードウェア構成
| サーバー #1 の構成 | サーバー #2 の構成 |
|---|---|
| プロセッサ: 2 x Gold 6152 @ 2.1Ghz | プロセッサ: 2 x Gold 6252 @ 2.1Ghz |
| メモリ: 192GiB DRAM | メモリ: 1.5TiB DCPMM + 192GiB DRAM |
| ストレージ: 2 x 750GiB P4800X Optane SSD | ストレージ: 2 x 750GiB P4800X Optane SSD |
| DCPMM: Memory Mode ＆ App Direct モード |
テスト 1: このテストでは、図 3 のサーバー #1 構成に示される Skylake サーバーにおいて前述の**T4 ワークロード**を実行しました。 Skylake サーバーは、2010 ジャーナル書き込み/秒のジャーナルファイル書き込み速度で約 3355 件のインバウンドメッセージの持続的なスループットを示しました。
テスト 2: このテストでは、図 3 のサーバー #2 構成に示される Cascade Lake サーバーにおいて、DCPMM の Memory Mode を指定して同じワークロードを実行しました。 これは、2400 ジャーナル書き込み/秒のジャーナルファイル書き込み速度で約 4684 件のインバウンドメッセージの持続的なスループットという大幅な向上を示しました。 これは、テスト 1 に比較すると 39% の増加です。
テスト 3: このテストでは、図 3 のサーバー #2 構成に示される Cascade Lake サーバーにおいて同じワークロードを実行しましたが、今度は DCPMM を App Direct Mode に指定し、DCPMM による何らかの実行を構成せずに実行しました。 このテストの目的は、DRAM のみを使用した Cascade Lake のパフォーマンスとスループットを DCPMM と DRAM を使用した Cascade Lake に比較して測定することです。 DCPMM が使用されていない場合でもスループットは（比較的小さいとは言え）向上したという、特に驚くことでもない結果が出ました。 これは、2540 ジャーナル書き込み/秒のジャーナルファイル書き込み速度で約 4845 件のインバウンドメッセージの持続的なスループットという向上を示しました。 DCPMM は DRAM に比べてより高いレイテンシがあり、更新が大量に流入すればパフォーマンスが低下するため、予想された動作と言えます。 別の見方をすると、まったく同じサーバーで DCPMM を Memory Mode で使用する場合、書き込みの取り込みワークロードに 5% 未満の低下があることになります。 また、Skylake を Cascade Lake（DRAM のみ）に比較した場合、テスト 1 の Skylake サーバーに比べて 44% の増加が得られています。
テスト 4: このテストでは、図 3 のサーバー #2 構成に示される Cascade Lake サーバーにおいて同じワークロードを実行しましたが、今度は DCPMM を App Direct Mode に指定し、App Direct Mode をジャーナルファイルシステム用にマウントされた DAX XFS として使用して実行しました。 これは 2630/秒のジャーナルファイル書き込み速度で 1 秒あたり 5399 件のインバウンドメッセージというさらに高いスループットを示しました。 この種のワークロードでは App Direct Mode の DCPMM がより適した DCPMM の使用方法であることが示されています。 これらの結果を最初の Skylake 構成と比較すると、テスト 1 の Skylake サーバーに比べ、スループットが 60% 増加しています。
Intel® Optane™ DC パーシステントメモリを使用することで InterSystems IRIS にメリットが与えられるユースケースと構成にはいくつかあります。
このモードは、単一の InterSystems IRIS デプロイや大規模な InterSystems IRIS シャードクラスタでの膨大なデータベースキャッシュに最適です。後者の環境ではより多く（またはすべて）のデータベースをメモリにキャッシュできます。 DCPMM と DRAM の比率は最大 8:1 にすることをお勧めします。「ホットメモリ」を L4 キャッシュレイヤーとして機能する DRAM に保持する際に重要です。 これは、リソース占有やその他のメモリキャッシュラインなど、共有内部 IRIS メモリ構造において特に重要となります。
このモードは、DCPMM をトランザクションジャーナルファイルのディスクデバイスとして使用する場合に最適です。 DCPMM は Linux にマウントされた XFS ファイルシステムとしてオペレーティングシステムに表示されます。 DAX XFS を使用するメリットは、これによって PCIe バスのオーバーヘッドとファイルシステムからのダイレクトメモリアクセスが緩和されることにあります。 HL7v2 ベンチマークの結果に示されるように、書き込みレイテンシによって HL7 メッセージングのスループットは大幅に向上します。 また、ストレージには従来のディスクデバイスと同様に、再起動や電源サイクル時における永続性と耐久性が備わっています。
このユースケースでは、App Direct モードの用法がトランザクションジャーナルと書き込みイメージジャーナル（WIJ）の両方に拡張されます。 両ファイルは書き込み集中型であるため、超低レイテンシと永続性のメリットを確実に得られます。
DCPMM を Dual Mode で使用すると DCPMM のメリットが拡大し、トランザクションジャーナルや書き込みイメージジャーナルデバイスで大規模なデータベースキャッシュと超低レイテンシを実現できるようになります。 このユースケースでは、DCPMM は OS にマウントされた XFS ファイルシステムとオペレーティングシステムの RAM として表示されます。 これは、DCPMM の一定の割合を DAX XFS に割り当て、残りを Memory Mode に割り当てることで可能です。 前述のように、インストールされている DRAM はプロセッサの L4 のようなキャッシュとして機能します。
疑似 Dual Mode 寄りにユースケースモデルを拡張するために、OLTPタイプのワークロード用と分析または大規模なクエリーニーズ用に高速のインバウンドトランザクションと更新が伴うトランザクションと分析の並行ワークロード（HTAP ワークロードとしても知られています）タイプのワークロードがあり、さらに InterSystems IRIS 共有クラスタ内ではそれぞれの InterSystems IRIS ノードタイプが DCPMM のさまざまなモードで稼働しています。
この例では、グローバルバッファの大規模データベースキャッシュと、トランザクションワークロード用に DAX XFS として Dual Mode または App Direct のいずれかで実行するデータノードのメリットを得られるように、DCPMM Memory Mode で実行する大規模なクエリ/分析ワークロードを処理する InterSystems IRIS 計算ノードが追加されています。
インフラストラクチャの選択に関して言えば、InterSystems IRIS には多数のオプションが提供されています。 インフラストラクチャの要件はアプリケーション、ワークロードプロファイル、およびビジネスニーズによって決まり、これらのテクノロジーとインフラストラクチャの選択が、ビジネスにおけるアプリケーションの成功、採用、および重要性を左右します。 第 2 世代 Intel® Xeon® スケーラブルプロセッサと Intel® Optane™ DC パーシステントメモリを使用した InterSystems IRIS は、ビジネスに大きな影響を与える InterSystems IRIS ベースアプリケーションに画期的なスケーリング性能とスループット性能を与えることができます。
InterSystems IRIS と Intel DCPMM 対応サーバーには、次のようなメリットがあります。
お客様の InterSystems IRIS ベースのアプリケーションに最適なハードウェア構成についてのご相談は、InterSystems テクノロジーアーキテクトにお問い合わせください。
開発者の皆さん、こんにちは！
HL7v2メッセージをFHIR（Fast Healthcare Interoperability Resources）に変換するニーズがあり、その変換プロセスが複雑で分かりにくいと感じたことはありませんか？インターシステムズは、HL7v2メッセージをFHIR（Fast Healthcare Interoperability Resources）に変換するプロセスを簡単にする、HealthShareメッセージ変換サービス(HealthShare Message Transformation Services)と呼ばれる新しいクラウドベースのSaaSサービスを展開しています。 この新しいサービスの早期アクセス・プレビュー・プログラムを発表できることを嬉しく思います。 必要なのは、無料のAWSアカウントと、HL7v2メッセージをドロップするためのS3バケット、そしてFHIR出力を得るための別のS3バケットだけです。
この機能の簡単なデモをご覧ください。
<iframe allow="encrypted-media" allowfullscreen="" frameborder="0" gesture="media" height="315" scrolling="no" src="https://www.youtube.com/embed/Js0SDUZbXv8" width="560"></iframe>
インターシステムズ社のラーニングサイトでは、AWS の無料アカウントとインターシステムズ社のクラウド・ポータルの無料アカウントにサインアップして、変換サービスの強力な機能を利用するための簡単なステップ・バイ・ステップ・ガイドを提供しています。 完全なドキュメントは、インターシステムズ社のドキュメントでご覧いただけます。
このサービスは、7月下旬に正式に開始される予定です。プレビューが終了しても、最初の100万件の変換を無料で利用することができます。
HealthShareメッセージ変換サービスの紹介。
医療IT業界では、FHIR® (Fast Healthcare Interoperability Resources)が、ヘルスケアデータを交換するための最新のデータ標準として採用されています。 オンデマンドのHealthShareメッセージ変換サービスを利用することで、医療機関、保険会社、製薬会社は、既存のデータフォーマットをFHIR規格に変換し、データから最大限の価値を引き出すことができます。 インターシステムズは、最新のFHIR規格だけでなく、HL7v2、X12、CDA、C-CDA、DICOMを含むすべての主要なヘルスケア規格を実装しており、ヘルスケアの相互運用性におけるリーダー的存在です。
HealthShareメッセージ変換サービスは、これらの以前の標準からFHIR R4へのメッセージ変換を簡単に行えるように設計されており、初期リリースではHL7 v2メッセージのFHIR R4への変換をサポートしています。 FHIRメッセージは、AWS S3バケットまたはAmazon HealthLake (Preview)に送ることができ、将来的には他のFHIRリポジトリオプションも追加される予定です。
HealthShareメッセージ変換サービスは、HL7v2メッセージをFHIRに変換することを簡単にします。 変換ロジックを気にする必要がないので、メッセージ変換の複雑な作業はインターシステムズに任せて、優れたヘルスケア・アプリケーションの構築に集中することができます。このサービスが提供するのは
さらに、このサービスはAWSのインフラ上に構築されているため、ISO 27001:2013およびHIPAAをサポートするHITRUST認証を取得しています。インターシステムズは、このサービスの運用、監視、バックアップを管理しています。
そして何より、このサービスが商業的に開始されると、最初の100万回の変換が無料で提供され、その後は使用した分だけを支払うことになり、変換されたメッセージあたりのコストは非常に低く抑えられます。 このサービスを利用するための長期契約はなく、いつでも解約できます。
皆様からのフィードバックをお待ちしております。 この記事のコメント欄にご意見をお寄せいただくか、 HMTS@InterSystems.com まで直接お問い合わせください。
HL7 ® と FHIR ® は Health Level Seven International の登録商標であり、これらの商標の使用は HL7 による推奨を意味するものではありません。FHIR商標の使用は、HL7によるHealthShare Message Transformation ServicesまたはHealthShare Message Transformation Servicesの推奨を意味するものではありません。
これは InterSystems FAQ サイトの記事です。
HL7 メッセージの送受信を行うプロダクションでは、以下３個のグローバルが非常に大きくなることがあります。
グローバルの大きさを確認する場合は、^%GSIZEユーティリティを利用します。詳細は関連トピック／記事をご参照ください。
^EnsHL7.Segment
^EnsLib.H.MessageD
^EnsLib.H.MessageI
HL7メッセージは EnsLib.HL7.Message.cls で定義されます。
^EnsLib.H.MessageD はデータを保存するグローバル、^EnsLib.H.MessageI はインデックスを保存するグローバルです。
また、HL7メッセージは多数のセグメントで構成されており、メッセージデータを含むそれらのセグメントは ^EnsHL7.Segment に保存されます。
^EnsLib.H.MessageD グローバルの値は、^EnsHL7.Segment グローバルの添え字にリンクしています。
これらメッセージ関連のグローバルの削除については、任意の保持日数を指定して手動および定期的に削除することができます。
パージ（Purge）用ユーティリティについては、以下のドキュメントをご参照ください。
関連トピック／記事
これは InterSystems FAQ サイトの記事です。
仮想ドキュメント（以降VDOC）とは複雑な構造のドキュメント（メッセージ）を効率良く高速に処理するために考えられたメッセージ処理の仕組みです。
HL7に代表される EDI 標準は電子データ交換のための汎用的なかなり複雑なメッセージ形式を含んでいます。
また、メッセージの種類を増やすと運用が複雑になってしまうため、1 つのメッセージに様々なデータを詰め込む傾向があります。
その結果 1 つのメッセージは複雑かつデータ量が多いものになりがちです。
一方、実際のメッセージ交換では、メッセージの全てのデータを処理することはまれで一部のデータのみが必要となるケースがほとんどです。
複雑なメッセージ構造から必要な項目を抽出して処理する際、メッセージを InterSystems IRIS data platform のオプジェクト指向フレームワークに基づき一度オブジェクトとしてインスタンス化することで処理を簡潔に記述できます。
しかし、データ量の多いメッセージを解析しオブジェクトにインスタンス化する処理は非常に負荷のかかる処理で、しかも大量のメッセージを処理しなければならない場合は求められるスループットを満たせない状況になりがちです。
しかも必要なデータは「全体の中のほんの少し」という状況の場合、無駄の多い処理となります。
皆さんこんにちは。
第5回 InterSystems IRIS プログラミングコンテスト（FHIRコンテスト） への応募は終了しました。コンテストへのご参加、またご興味をお持ちいただきありがとうございました。
今回のお知らせでは、見事受賞されたアプリケーションと開発者の方々を発表します！
🏆 審査員賞 - 特別に選ばれた審査員から最も多くの票を獲得したアプリケーションに贈られます。
🥇 1位 - $1,500 は iris-fhir-portal を開発された Henrique Gonçalves Dias さんに贈られました！
🥇 1位 - $1,500 は iris4health-fhir-analytics を開発された José Roberto Pereira さんに贈られました！
🥉 3位 - $500 は fhir-chatbot を開発された Renato Banzai さんに贈られました！
🏆 開発者コミュニティ賞 - 最も多くの票を獲得したアプリケーションに贈られます。
🥇 1位 - $1,000 は iris-fhir-portal を開発された Henrique Gonçalves Dias さんに贈られました！
🥈 2位 - $500 は iris4health-fhir-analytics を開発された José Roberto Pereira さんに贈られました！