ヘルスケアデータレイクを始めよう

この記事は “ Getting started with a healthcare data lake ” を翻訳したものです。

ヘルスケアに関連するデータは、量と種類の両面において驚異的な拡大を続けています。International Data Corporation (IDC)¹ によると、2018 年時点の世界のヘルスケアデータは 1,218 exabytes (エクサバイト) と推定され、年平均成長率 (CAGR) についても 36％と、今後も急速に急増していくことが予想されています。さらに Hong et al² は、このデータの管理は、技術的な不均一性から適切なレベルのセキュリティとプライバシーの維持の難しさに至るまで、無数の課題があるため、ヘルスケア業界に大きな障壁をもたらすと指摘しています。しかし、これらは乗り越えなければならない障壁です。Amazon とその他の企業が共同で発表した Cloud Healthcare Pledge にあるように「適切な許可と制御を伴ったヘルスケアデータのスムーズな交換は、ヘルスエコシステム全体において、より良い患者ケア、より高いユーザー満足度、さらなるコスト削減につながる」のです。

複雑なデータ統合に取り組む最良の方法の 1 つがデータレイクです。データレイクとは、すべてのデータを、元の形式でも分析用に準備された形式でも保存する、一元的に管理・保護されたリポジトリのことを指します。データレイクを利用することで、データのサイロをなくし、データウェアハウス、ビッグデータ処理、オペレーション分析などの異なるタイプの分析を組み合わせて洞察を得ることで、より良いビジネスの意思決定を導くことができるようになります。

ヘルスケア分野では Grand River Hospital のように初期のデータレイク構築に関する成功例がある一方で、クラウド導入はまだ初期段階にあります。私は、お客様がクラウドを導入する際に「クラウドによる変革でチームをリードする」というセッションを必ず紹介します。このセッションは、導入に際しての非常に具体的なガイダンスを提供しています。ここで得られる洞察は、当社のクラウド変革成熟度モデルと一致しています。当社では Project (プロジェクト)、Foundation (基盤)、Migration (移行)、Optimization (最適化) という導入における 4 つの主要段階を特定し、最初の大きなワークロードに取り組むために専用の「 Two-Pizza チーム」を確立し、すべての組織レベルでクラウドの採用を拡大するための強固な基盤を構築することを推奨しています。

このブログでは、組織の最初の重要なプロジェクトとして、データレイク構築するためのステップバイステップのガイドを提供します。私たちの初めのゴールは、あるフォーマットのメッセージを受け取り、それを自動的に別のフォーマットに変換することです。コストと継続的な管理を最小限に抑え、誰もがアクセスできるようにするため、オープンソースとサーバーレスの技術を利用します。さらに、すべてのエンドアーティファクトは AWS CloudFormation を使用して Infrastructure as Code (IaC) としてデプロイされます。

最初のメッセージ変換では HL7 v2 メッセージを Encoding Rules 7 (ER7, 別名 “Pipehat”) から JSON に変換することにします。HL7 のバージョン 2.x (V2) のメッセージ標準は、診療領域における電子データ交換でよく利用される形式であり、世界で最も広く実装されている医療技術標準です。米国の医療機関の 95％が HL7 V2.x を使用しており 35 カ国以上で HL7 V2.x の実装が行われています。

スプリント 1 のアーキテクチャ

初回のセットアップ：

ER7 形式の HL7 v2.x メッセージを、直接ファイルアップロードしてデータレイクの “raw zone” に保存します。データレイクの重要な特徴の 1 つは監査可能なように現状のままデータを保存することです。
raw ゾーンでファイルの保存を受信すると Lambda 関数をトリガーして変換処理が実行されます。
Lambda 関数は Lambda レイヤーとしてオープンソースの HL7 2.x 構文解析ライブラリ “ HL7apy ” を使用して、オブジェクトを再フォーマットします。
再フォーマットに成功したオブジェクトは、データレイクの “staging zone” に置かれ、失敗した場合は “error zone” に置かれます。
データが標準形式になったので、 Amazon Athena などのツールを使ってデータを表示したりクエリしたりすることができます。

解説

前提条件

適切な権限を持つ AWS アカウント。 AWS アカウントをお持ちでない場合は作成し有効化してください。
Python スクリプトの基本的な知識。コーディングとデプロイに使用するスクリプトは Python で AWS SDK for Python である “boto3“ を使用します。

環境設定

このデモでは、開発環境として AWS Cloud9 を使用しています。以下のコマンドはすべて Cloud9 内で実行されるため、ターミナルコマンドはすべて Linux ベースとなります。

Cloud9 のドキュメントにある “EC2 環境の作成” の手順を実施します。
以下のターミナルコマンドで Git リポジトリをクローンします。
git clone -b blog_1 https://github.com/aws-samples/hcls-data-lake.git
cloud9_init.sh を実行して、必要な Python ライブラリをインストールします。
（訳者注：cd hcls-data-lake 後に bash cloud9_init.sh にて実行できます）
deploy_data_lake.py を実行して、スタックをデプロイします。
（訳者注：python ./deploy_data_lake.py にて実行できます）

各ファイルの概要

deploy_data_lake.py

これは AWS リソースをデプロイするために IDE 内で実行するファイルです。以下の処理を行います：

Lambda Layer の準備
1. HL7apy ライブラリをダウンロードします
2. 初期パッケージの “.tar.gz “を展開します
3. Python ランタイムがサポートするトップフォルダ (ここでは “python” という名前のフォルダ) にコンテンツを配置します
4. 圧縮して “.zip” パッケージに戻します
5. 一時的な Amazon Simple Storage Service (Amazon S3) のバケットに新しいパッケージをアップロードします。
Lambda 関数を zip で圧縮し、Lambda レイヤーでパッケージをアップロードした際に利用した、一時的な Amazon S3 のバケットに入れます。
CloudFormation スタックをデプロイします。
一時的なリソースをクリーンアップします。

スクリプトのいくつかの部分について説明をします：

boto3 オブジェクトの複数の constructors : リージョンが指定されていない場合 boto3 はリソース作成時にデフォルトで ‘us-east-1′ を使用します。他のリージョンを使用する場合はコンストラクタで指定します。
waiters の使用 : boto3 の多くの操作は非同期で実行されます。依存関係があるため (例：オブジェクトの S3 へのアップロードを完了してから参照する)、スクリプトが順番に処理を実行し完了するように wainters を使用しています。
一時的なバケットの使用 : Lambda 関数や Lambda Layer などのいくつかのリソースは、 S3 バケットに .zip ファイルとして用意されていることが CloudFormation に要求されています。

hl7_parser.py

再フォーマットを実行するシンプルな関数です。いくつか注意点があります：

S3 オブジェクトのリファレンスが渡されることを想定しています。
1 つのオブジェクトで複数の HL7 v2 メッセージを扱うことができ、それぞれを個別に出力します。
HL7 バージョン仕様に厳密に従った “happy path” でのみ動作します。それ以外の “messy” やカスタマイズされたメッセージなどでは error zone に配置されます。
JSON 配列を使用する場所を決定するために HL7 仕様で定義された要素の “repetitions” を使用します。

hl7_stack.yml

CloudFormation にて使用されるテンプレートです。主な注意点は、データレイクバケットを参照するために “!Sub” 関数を使用していることです (例 : !Sub "arn:aws:s3:: ${IngestBucket}" ) 。これは、以下の赤で示したようにアーティファクト内で循環参照するために必要です。!Sub 関数を使用することで CloudFormation にリソース名を導き出させるのではなく、データレイクバケットの ARN の文字列を直接提供することになるため、このループを解消することができます。

データレイクを利用する

HL7v2 メッセージを含むファイルをアップロードする

ファイルをアップロードし、新しいデータレイクを利用することができます。

AWSコンソールにログインし Amazon S3 の管理コンソールに移動します。
データレイクバケットを選択し “Create Folder” ボタンを押し “raw” という新しいフォルダを作成します。これは、新着の HL7 v2 メッセージを確認するために Lambda トリガーが設定されている場所です。 S3 のオブジェクトはフラットな構造であり、フォルダとは単に組織的な簡略化のための概念に過ぎないことに注意してください。
（訳者注：データレイクバケットは “hl7v2-ingestion-” から始まる名前で作成されています。S3バケットの検索ボックスからご確認ください）
新しく作成したフォルダに移動し “Upload” ボタンを選択し HL7 v2 メッセージを含むテキストファイルをバケットの raw フォルダにアップロードしてください。簡単のため Cloud9 にダウンロードしたパッケージにいくつかのサンプルが含まれていますが、ここにあるサンプルを使用することもできます。
（訳者注：Cloud9 環境の message フォルダ下に adt01.txt や adt02.txt というファイル名でテキストファイルが格納されています。ファイルを右クリックし、ダウンロードすることが可能です。）
```
MSH|^~\&|SOURCEEHR|WA|MIRTHDST|WA|201611111111||ADT^A01|MSGID10001|P|2.3|
EVN|A01|201611111111||
PID|1|100001^^^1^MRN1|900001||DOE^JOHN^^^^||19601111|M||WH|111 THAT PL^^HERE^WA^98020^USA||(206)555-5309|||M|NON|999999999|
NK1|1|DOE^JANE^|WIFE||(206)555-5555||||NK^NEXT OF KIN
PV1|1|O|1001^2002^01||||123456^DOCTOR^BOB^T^^DR|||||||ADM|A0|
```
アップロードが完了すると Bucket のルートに戻り、新しいフォルダが表示されるはずです。アップロードが成功した場合、そのフォルダは “staging” と表示されます。その場合、ステージングフォルダに移動し、新しく作成されたファイルを確認します。

AWS Glue でのカタログと Amazon Athena での表示

データを照会するには、まず AWS Glue Data Catalog を作成する必要があります。これはデータのスキーマを生成します。このセクションに記載されているすべてのアウトプットは、迅速な実験のために一時的にコンソールを介して手動で作成されたことに注意してください；本番環境では CloudFormation などのサービスを通じてこれらを定義し管理すると良いでしょう。

AWS Glue に移動し正しいリージョン (アーティファクトをデプロイした場所) であることを確認します。
サイドメニューにある Crawlers に移動し “Add Crawler” を選択する。
好きな名前を付けてください。 “hl7-temp-crawler” をお勧めします。
“Crawler source type” はデフォルトの “Data stores” のままにしておきます。
データストアの種類は “S3” のままで “Specified path in my account” にデータをクロールします。パスは “s3://$bucket/staging/” で “$bucket” の部分をデータレイクバケットの名前に置き換えます (例：s3://hl7v2-ingestion-74fd3987-56eb-4ff0-b2af-d92e290ef0e0/staging/ )。
“add another data store” は “No” のままにしておきます。
IAM ロールを作成するを選択します。“temporary-data-lake” のようなわかりやすい名前をつけます。
実行頻度を “Run on demand” のままにします。
クローラーの出力について :
1. データベースを追加し “temporary-hl7-data-lake” のようなわかりやすい名前をつけます。
2. “Grouping behavior for S3 data (optional)” で “Create a single schema for each S3 path” の横にあるチェックボックスをオンにします。これは各 HL7v2 メッセージが持つ可能性のある、異なるスキーマを同じテーブルに保持するためです。
3. 他のオプションはすべてデフォルトのままにしておきます。
“Finish” を選択するとダッシュボードに戻り、新しいクローラーを実行するかどうかを尋ねるポップアップが表示されます。 “Run it now?” を押してください。実行にかかる時間はメッセージのサイズに依りますが、上記のサンプルメッセージの場合は完全に完了する (つまり “Ready” 状態に戻る) までに約 1 分かかります。

クローラーが完了したら Amazon Athena でデータにクエリをかけることができます。

Amazon Athena に移動し、正しいリージョン (バケットをデプロイして Glue を実行した場所) であることを確認します。
起動画面が表示されたら “Get Started” をクリックします。
Query Editor ダッシュボードで、左側のメニューからデータベースを選択します。
JSON オブジェクトとして表現された HL7 セグメントが、データベースのトップレベルアイテムとして表示されるはずです。ドット表記を使用することで、オブジェクト内のクエリを実行することができます。たとえば、次のクエリは、メッセージ ID 、患者 ID 、名前、および姓を引き出します：
```
Select msh.message_control_id, pid.set_id_patient_id, pid.patient_name.given_name, pid.patient_name.family_name 
FROM staging
```

まとめと次のステップ

このブログでは、医療機関がデータレイクを構築する際に取り得る最初のビルディングブロックについて示しました。データレイクパターンの重要な強みの 1 つは様々な方向への拡張性があることです。次のステップとして何を望むか、コメントでお聞かせください。例えば以下のような例があります。

AWS Lake Formation によるセキュリティ、最適化、アクセス性、レコードマッチングなどの高度な機能の活用。ここからさらに Amazon Comprehend Medical による個人健康情報 (PHI) や医療機関の抽出、 Amazon DynamoDB によるデータのトークン化などの追加機能に踏み込んでいくことができます。
Amazon API Gateway の HTTP API をメッセージ取り込みの追加手段として追加します。
別の医療用独自フォーマットのデータレイクへの変換。よくある例としては DICOM の場合 .dcm ファイルを画像とテキスト属性に分離して、保存方法を最適化し、格納されたデータの分析を可能にすることが挙げられます。

以下のコメント欄にご意見をお寄せください。また、公共部門におけるヘルスケアのページ、ヘルスケア、データレイクに関するその他のブログも併せてご覧ください。

AWS Public Sector Blogのニュースレター(英語) に登録すると、公共部門からのAWSツール、ソリューション、イノベーションの最新情報を受信トレイにお届けします。またこちらからお問い合わせにも対応しています。

¹ IDCホワイトペーパー, sponsored by Seagate, “Data Age 2025: The Digitization of the World from Edge to Core“, November 2018.
² Hong, Liang, et al. “Big Data in Health Care: Applications and Challenges.” Data and Information Management, Volume 2, Issue 3, 1 December 2018, Pages 175-197.

著者について

Neil McFarlane

Neil McFarlane は、ヘルスケアに特化した Amazon Web Services (AWS) のソリューションアーキテクトです。相互運用性、データ分析、電子カルテを専門分野としています。

翻訳は Solutions Architect 片山洋平が担当しました。原文はこちらです。

Amazon Web Services ブログ