FHIR Object Modelを使ったInteroperability開発

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

突然ですが、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テンプレートエンジンとなにが違うの？メリット・デメリットは？書き替えた方がいいの？
だいぶ主観が入りますが、JSONテンプレートエンジンとの比較をしてみたいと思います。

 

1.1. JSONテンプレートエンジンとなにが違う？

JSONテンプレートエンジン
こちらは、テンプレートクラスに記載されたテンプレートを元に、プロパティやパラメータ値を設定してJSONデータを出力します。
一方、FHIR Object Modelは、FHIRの全リソース構造を網羅したクラスを元に、プロパティを設定してFHIRオブジェクトに変換し、操作・編集が容易なクラスライブラリです。より詳細を知りたい方は、冒頭のリンクのYouTube動画を見ていただくと理解が深まると思います。

1.2. メリット・デメリットは？

• メリット

1. 自身でなにも用意しなくていい！ゼロベースで（IRIS for Healthをインストールさえしてあれば）使える
2. オフィシャルのためIDEのサポートが充実
3. DynamicAbstractObjectとの相互変換メソッド

• デメリット

1. 入れ子になったオブジェクトの操作は慣れが必要
2. カスタムプロファイルに対応したモデルクラスがない
3. 日本語ベースのドキュメントがほぼない

 

1.3. 書き替えた方がいいの？

 

個人的な意見は NO です。なぜならば、FHIR Object ModelはあくまでFHIR開発のサポートを行うためのツールであり、既に実装済みのコードがあるのであれば、書き替えるほどの強力なインパクトはありません。

 

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

• メリット

1. 自身でなにも用意しなくていい、という真意は、JSONテンプレートエンジンを利用しようとすると、どうしても自身でテンプレートクラスを作成しなくてはいけない作業が発生します。JSONテンプレートエンジンは、用意されているリソースの数に限りがあるのと、元々退院時サマリーのFHIRモデルをベースにしたテンプレートのためです。一方、FHIR Object Modelは、現状R4ベースという制限はあるものの、リソース定義がすべてクラス化されており、使い方さえわかればすぐ開発に取り掛かれます。
2. IDEのサポートが充実しているのは、自動入力補完機能（オートコンプリート）が利用できるのと各メソッド、各プロパティにDescriptionがちゃんと（英語ですが）ついていることに尽きると思います。
3. セミナー内の絵を拝借しますが、文字列、ダイナミックオブジェクト、FHIR Modelオブジェクトは、各クラスごとに用意されているメソッドで相互に変換でき、利用の幅が広がります。

 

• デメリット

1. IncludeXXXX() と MakeEntry()、そして add() する順番などが最初混乱しました。慣れてしまえば問題はないかと。
2. カスタムプロファイルに対応したモデルクラスがないのは惜しいです。今後のリリースに期待いたします。
3. まだ新しい機能なので、使い方や応用、実務向けサンプルなどが少ないです。だからこそ本記事を書いております。少しでもご参考になれば幸いです。

3. GitHub公開ソースについて

リポジトリタイプのInteroperabilityをコードベースで作成しました。
環境は、コンテナで動作するIRIS for Health Community 2024.1です。
インプットデータはCSVファイルで、レコードマップを定義しています。

• Patientリソースを作成するためのPatient.csv
• Observationリソースを作成するためのBodyMeasurement.csv

の２つを用意しており、どちらのリソースもサンプルのCSVを取り込むと常にBundleリソースに含めてtype=transactionでPOSTする形式です。

set bundle = ##class(HS.FHIRModel.R4.Bundle).%New()
set bundle.type = "transaction"
do bundle.IncludeEntry()
// ここまでは初回(bundle.entryに初めてaddするとき)のみ実行
set entry = bundle.entry.MakeEntry()
set entry.fullUrl = "urn:uuid:"_$ZCONVERT($SYSTEM.Util.CreateGUID(),"L")
do entry.IncludeResource()
// resource = HS.FHIRModel.FHIRClassSuper(HS.FHIRModel.R4.Patientなど)
set entry.resource = resource
do entry.IncludeRequest()
set entry.request.method = "POST"
set entry.request.url = resource.resourceType
do bundle.entry.add(entry)

とはいえ、Patientリソースのほうは「identifier.system|identifier.value」の条件で、存在すればPOSTしないifNoneExistプロパティを追加していますので、同じ患者IDのPatientリソースは作成されないようにしています。

// GitHubソース上では、先述のコードサンプルの bundle.entry.add() の前に入れ込んでいます
set:resource.resourceType="Patient" entry.request.ifNoneExist = "identifier=urn:oid:1.2.392.100495.20.3.51.11234567890|"_resource.identifier.get(0).get("value")

概要図はコチラです。

 

4. 所感

新機能！と思って飛びついてみましたが、IRIS経験者であればさほど苦も無く利用できると思います。
オフィシャルであることも強みで、今後の拡張やサポートにも期待しております。
GitHubのソースについて、なにかご質問あればコメントください。わかる範囲でご回答いたします。