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

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

InterSystems OMOP クラウドサービスの期限切れ間近のトライアル版を通じた OHDSI（「オデッセイ」と読む）コミュニティに対する実装者のアプローチ

InterSystems OMOP とは？

InterSystems OMOP は、InterSystems クラウドサービスポータルを介して HealtheShare サービスとして提供されており、HL7® FHIR® データを Observational Medical Outcomes Partnership（OMOP）共通データモデル（CDM）に変換します。 InterSystems OMOP は S3 バケットに格納されている FHIR データを参照し、自動的に変換処理を行って、そのデータを OMOP CDM 形式でクラウドホスト型リポジトリに送信します。 するとユーザーは、ATLAS や HADES などの外部の Observational Health Data Sciences and Informatics（OHDSI）ツールと新しいタブに開く JDBC などのデータベースドライバーを併用して、データの分析タスクを実行できるようになります。

要約: S3 にホストされた FHIR Bulk Export データを OMOP CDM に変換し、クラウドホスト型の IRIS または postgres 構成の任意のデータベースに変換します。

ここでは、上記の「フルコース」を試して、最新の強力なツールと OHDSI コミュニティのアプリケーションの驚くべきエコシステムに囲まれた実装を最初から最後まで実行します。あちらこちらでドキュメントを使いまわさないようにし、その過程で地雷 👣 🔫 を紹介します。

素敵なものはバケットから生まれる

初めてサービスをプロビジョニングし、作成ダイアログにアクセスして入り口でS3の情報を尋ねられると、すぐに鶏と卵の状況にあるように感じられるかもしれません。これをできる限りうまく偽装して後で更新することも、変換用に Amazon S3 バケットをどのようにプロビジョニングするかを理解した上で、落ち着いたアプローチをとることも可能です。これは、データを共有するためにほとんどのクラウド型データソリューションに実装されている最新のアプローチです。ソースの場所を自分でプロビジョニングして、サービスにその場所と対話するためのアクセスを許可します。

• バケットと初期ポリシースタックのプロビジョニング
• サービスのデプロイメントの作成
• デプロイメントに制約されたバケットポリシーの更新

コンソールをクリックして終了するか、サンプルスタックでこれを行うことができます。

---
AWSTemplateFormatVersion: '2010-09-09'
Description: AWS Cloudformation Stack that will create the S3 Bucket and Policy for the OMOP Server
Parameters:
  BucketName:
    Description: The name of the bucket to use to upload FHIR Bundles for Transformation.
    Type: String
    AllowedPattern: "^[a-z0-9][a-z0-9-]{1,61}[a-z0-9]$"
  PolicyfromOMOPConfiguration:
    Description: The name of the bucket to use to upload FHIR Bundles for Transformation.
    Default: "arn:aws:iam::1234567890:role/skipper-deployment-*-Role"
    Type: String
Resources:
  OMOPFHIRTransactionBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub ${BucketName}
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
  OMOPBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref OMOPFHIRTransactionBucket
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - !Sub ${PolicyfromOMOPConfiguration}
            Action:
              - "s3:GetObject"
              - "s3:GetBucketLocation"
              - "s3:ListBucket"
            Resource:
              - !Sub "arn:aws:s3:::${BucketName}"  # Bucket itself
              - !Sub "arn:aws:s3:::${BucketName}/*"  # FHIR Objects within the bucket

スタックは任意の方法で作成できます。1 つの方法として AWS CLI を使用できます。

aws cloudformation create-stack --stack-name omopfhir --template-body s3-omop-fhir-bucket.yaml --parameters ParameterKey=BucketName,ParameterValue=omop-fhir

バケットに、プロビジョニングと FHIR 取り込み用のソースフォルダで使用する初期キーを作成します。

aws s3api put-object --bucket omop-fhir --key Transactions/in --profile pidtoo
aws s3api put-object --bucket omop-fhir --key termz --profile pidtoo

これで、次のようにしてサービスをプロビジョニングするように設定できるはずです。arn を要求するフィールドに注意してください。説明では名前を要求しているにもかかわらず、実際にはバケットの arn を要求しています... 小さな 👣🔫 がここにあります。



デプロイメントが作成されたら、「FHIR から OMOP へのパイプライン」内にある「構成」ナビゲーション項目に移動し、ポリシーをクリップボードにコピーします。そこにある指示に従って、これを現在のポリシーに組み込むか、ロールの値を取得してスタックを更新します。

aws cloudformation update-stack --stack-name omopfhir --template-body s3-omop-fhir-bucket.yaml --parameters ParameterKey=PolicyfromOMOPConfiguration,ParameterValue="arn:aws:iam::1234567890:role/skipper-deployment-4a358965ec38ba179ebeeeeeeeeeee-Role"

いずれにしても、ソースバケットのアクセス許可には、このようなポリシーが表示されるはずです... （アカウント番号、ロールは不明瞭です）

{
    "Version": "2012-10-17",
    "Statement": [
    {
      "Principal": {
        "AWS": "arn:aws:iam::123456789099:role/skipper-deployment-33e46da9bf8464bbe5d1411111-Role"
      },
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::omop-fhir",
        "arn:aws:s3:::omop-fhir/*"
      ],
      "Sid": "IRIS Cloud Bucket Access"
    }
    ]
}

私は、ルートアカウントを開くことを許可しながらもバケットを制限する、よりオープンなポリシーを使用しました。こうすることで、1 つのバケット（または複数のバケット）で複数のデプロイメントをサポートできます。あまりお勧めできませんが、IAC の目的で単一のポリシーで複数の環境をサポートするための参考としての 2 番目の例です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111:root",  ### Entire accounts(3)
                    "arn:aws:iam::222:root",
                    "arn:aws:iam::333:root"
                ]
            },
            "Action": [
                "s3:GetObject",
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::omop-fhir",
                "arn:aws:s3:::omop-fhir/*",
                "arn:aws:s3:::omop-fhir2",
                "arn:aws:s3:::omop-fhir2/*"
            ],
            "Condition": {
                "StringLike": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::111:role/skipper-deployment-*-Role",
                        "arn:aws:iam::222:role/skipper-deployment-*-Role",
                        "arn:aws:iam::333:role/skipper-deployment-*-Role"
                    ]
                }
            }
        }
    ]
}

これが変換のソースです。では、ターゲットである OMOP データベースに移りましょう。

OMOP の紹介

もう 1 つのデプロイメントである「IRIS 上の OMOP」を簡単に見ながら共通データモデルをご紹介します。

OMOP（Observational Medical Outcomes Partnership）データベースは、複数のソースをサポートするために途方もない複雑さを、CDM と呼ばれる共通データモデルにまとめる方法を示す記念碑的なものです。コミュニティ外部のさらに詳しい説明は、コピペコンテンツ（またはさらに酷い生成コンテンツ）になりますが、このコミュニティのドキュメントは本当によくできています。

「SQL クエリツール」ナビゲーションに移動すると、InterSystems の共通データモデルの実装を確認できます。これは、OHDSI コミュニティのよく知られた OMOP スキーマの図の横に表示されます。

この作業はここまでです。変換目的のみでサービスを使用するためのもう 1 つのオプションを調べてみましょう。

BYODB（所有データベースの持ち込み）

前回プロビジョニングした際に、データベースを無料で入手しましたが、別のデータベースをターゲットにする場合は、この記事を書いた時点でサービスが Postgres 構成への変換もサポートしたため、確実に行えます。このために、Amazon RDS を介して外部データベースを操作し、サービスに接続する方法を説明します。

計算

ここにフラグを立てて、もう 1 つの 👣🔫 に注意を喚起しようと思います。独自のデータベースを持ち込む場合、サービスに合わせてデータベースのサイズを決定する際に「Biggie Smalls」と呼んでいます。InterSystems は、データベース側に対する変換側のサイズ設定を非常に適切に行うため、変換パフォーマンスの速度は書き込み先の SQL インスタンスに依存するという事実を考慮し、それに応じて行う必要があります。一部の人にとっては当たり前のことかもしれませんが、RDS、Google Cloud SQL などを安く利用​​したため、OMOP データベースへの FHIR バンドルの永続時間に影響が出ました。これを目撃したときに、指摘しておこうと思いました。

そうは言っても、私はまったく逆のことをしています。Jeff Bezos に可能な限り最小限の金額を渡し、db.t4g.micro postgres RDS インスタンスを使用しています。

これを公開して、データベースに対応するリージョンの証明書バンドルのダウンロードに移ります。 .pem 形式であることを確認してください。

次に、データベースとの対話方法に関係なく、データベースインスタンスに接続し、DATABASE と SCHEMA を作成します。

OMOP CDM 5.4 のロード

では、OHDSI コミュニティの友人たちの協力を得て、OHDSI ツールを使用して、OMOP 共通データ モデル スキーマを含む RStudio バージョン 5.4 でサポートされているスキーマをプロビジョニングしましょう。

install.packages("devtools")
devtools::install_github("OHDSI/CommonDataModel")
install.packages("DatabaseConnector")
install.packages("SqlRender")
Sys.setenv("DATABASECONNECTOR_JAR_FOLDER" = "/home/sween/Desktop/OMOP/iris-omop-extdb/jars")
library(DatabaseConnector)
downloadJdbcDrivers("postgresql")

必要なものが揃ったので、postgres インスタンスに接続し、上記でプロビジョニングした OMOPCDM54 にテーブルを作成しました。

接続

cd <- DatabaseConnector::createConnectionDetails(dbms = "postgresql",
                                                 server = "extrdp-ops.biggie-smalls.us-east-2.rds.amazonaws.com/OMOPCDM54",
                                                 user = "postgres",
                                                 password = "REDACTED",
                                                 pathToDriver = "./jars"
                                                 )

作成

CommonDataModel::executeDdl(connectionDetails = cd,
                            cdmVersion = "5.4",
                            cdmDatabaseSchema = "omopcdm54"
                            )

「赤い海」を除けば、正しく実行できたことでしょう。



では、作業内容を確認しましょう。サービスとの使用に適した外部の postgres OMOP データベースがあるはずです。

OMOP Cloud Service の構成

ソースもあり、ターゲットもあります。では、サービスを構成したこれらを繋ぎ合わせ、FHIR から外部データベースへの変換パイプラインを完成させましょう。


InterSystems OMOP Cloud Service の準備が完了しました！

OMOP の旅はまだまだ続きます...