医療提供者へのHL7ベースの通知機能をAWSクラウドに導入する方法

この記事は、“How to deploy HL7-based provider notifications on AWS Cloud” を翻訳したものです。

患者に関するイベントの電子通知は、医療機関がケアの連携を向上させ、適切な追加治療をタイムリーに推進するために不可欠な仕組みです。2020年5月、CMS（Center for Medicare and Medicaid Services）は、Critical Access Hospitals を含む米国のすべての病院に対し、入院、転院、退院に関する患者イベント通知を電子的に提供することを求める最終規則を発表しました。

カナダでは、連邦レベルでの法制化はまだですが、オンタリオ州を含む個々の州では、独自の電子医療記録（EHR）ソリューション（OntarioMD HRMソリューション）を通じて通知を配信し始めています。

世界経済フォーラムによると、データのサイロ化と情報交換の不足は、歴史的に不十分な患者ケアと高価な是正処置につながったとして、「政府の政策は、データの真の可能性を引き出すための、技術的な対応能力を検討しなければならない」としています。さらに、ハーバード・ビジネス・レビューでは、データサイエンスでは、作業の80%がデータの準備と収集に関わるものであり、データのサイロ化がその作業をさらに厳しいものにしていると述べています。

しかし、データ管理はそのような厳しいものである必要はないのです。この記事では、AWS Lambda、Amazon Comprehend Medical、AWS FargateなどのAmazon Web Services（AWS）のテクノロジーを組み合わせることで、AWS Well-Architected Frameworkに沿った安全かつ効率的な方法で、ヘルスケア関連のお客様が電子通知を配信するために、効果的にデータを管理および配信する方法を紹介します。

ソリューションの概要

提案するアーキテクチャは、受信した標準的なHL7メッセージに基づき、医療提供者に直接通知を配信する機能を提供します。標準的なメッセージングを活用することで、病院は既存のシステムへの影響を最小限に抑え、ソリューションの互換性を最大化することができます。

画像 1.上のアーキテクチャ図は、全体設計の概要を示しています。
個々の手順については、以下の「ソリューションのウォークスルー」セクションで説明します。

ソリューションのウォークスルー

このソリューション全体のフローを以下のステップでまとめました。

最小の下位層プロトコル (MLLP) (訳注：HL7 MLLP=HL7 Version2.x Messaging) は暗号化をネイティブにサポートしていないため、保護された医療情報（PHI）をAWSクラウドに安全に転送するには、AWS Site-to-Site VPNまたはAWS Direct Connect接続が必要です。
AWS Fargate コンテナ群は HL7 の終端として機能し、受信メッセージをAmazon Simple Queue Service(Amazon SQS) キューに配置します。
Amazon SQS はプロセスを分離し、受信メッセージの量に応じたスケーラビリティをサポートします。
AWS Lambda 関数は、 Amazon Comprehend Medical を使用して状況に応じた通知を準備します。セキュリティのステップとして、受信したHL7 メッセージに含まれる患者、医療提供者、および配信先の情報を検証するために、マスターデータ管理 (MDM) レジストリを照会する必要があります。
Amazon Comprehend Medical は、医療の固有表現抽出 (NERe) と医療オントロジーのリンク (ICD-10-CM) を提供しています。（訳注: 2022年1月現在、英語のテキストでの医療エンティティを検出します。）
Amazon Simple Email Service (Amazon SES) は、E メールで医療提供者に通知します。

前提条件

このソリューションを導入するためには、以下の前提条件が必要です。

AWS アカウント
MDM ソリューションを深く掘り下げることで、患者のケアサイクル全体を巻き込んで通知の到達範囲を拡大し、HL7 メッセージが注入されるリスクを軽減するために、個人情報と配送先のアドレスを検証する重要なセキュリティのステップとして機能します。MDMベンダー固有のAPIや、もし利用可能ならPIX/PDQ (訳注：IHE ProfileのPatient Identifier Cross-referencing(患者ID相互参照)とPatient Demographics Query(患者基本情報の問合せ)) のような医療標準を活用し、前述の検証を行うことは読者次第です。この記事では、受信する HL7 メッセージの中で、患者や医療従事者の情報が、標準にしたがって指示されたとおりにトランザクション的に利用できるようになっていることを前提としています。
このソリューションのAWS Fargateレイヤーでは、HL7を処理するソフトウェアが必要です。MLLPとAmazon SQSをすぐにサポートできるApache Camelを利用することをお勧めします。

セキュリティのベストプラクティスとして、Apache Camel ルート定義に静的な AccessKey とsecretKey を指定するのではなく、一時的な認証情報を利用します。これを行うには、コンテナ内部からアクセス可能な以下の URL でホストされているタスクロールの認証情報を収集することになります。

http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

useDefaultCredentialsProvider オプションが true に設定されている場合、URL からの認証情報の取得は Apache Camel によって実行されます。

Amazon Elastic Container Service (Amazon ECS) エージェントは、タスクに属するすべてのコンテナに対して、 Env オブジェクト (docker inspect container_id コマンドで利用可能) の AWS_CONTAINER_CREDENTIALS_RELATIVE_URI 環境変数に、以下の相対 URI を入力します。

/credential_provider_version/credentials?id=task_credential_id

public class MyRouteBuilder extends org.apache.camel.builder.RouteBuilder {

	@Override
	public void configure() {
		
		from("mllp:0.0.0.0:17000")
		.process(new MyLogProcessor())
		.bean(new MyTransformer(),"TransformContent")
		.to("aws2-sqs://arn:aws:sqs:region:accNum:queueName?useDefaultCredentialsProvider=true" );
	}
}

AWS Fargate タスクが依存するすべてのサービス (例: Amazon SQS、 Amazon CloudWatch など) にアクセスできるように、適切な AWS Identity and Access Management (IAM) ロールが設定されていることを確認する必要があります。

上記のコードは AWS Fargate タスク内で以下を実行します。

ローカルポート 17000 に MLLP HL7 リスナーを作成します。
MyLogProcessorクラスとMyTransformerクラスでそれぞれロギングと変換を処理します。
メッセージをqueueNameという名前のAmazon SQSキューに、一時的な認証情報を使用して転送します。

Apache Camel ルートを設定したら、次の dockerfile の例を使用してコンテナイメージをビルドできます。ビルドが完了したら、Amazon Elastic Container Registry (Amazon ECR) にコンテナイメージを登録します。

FROM maven:3.8.1-amazoncorretto-8 AS build
COPY src /home/app/src
COPY pom.xml /home/app
RUN mvn -f /home/app/pom.xml clean package

FROM amazoncorretto:8
COPY --from=build /home/app/target/hl7receiver-0.0.1-SNAPSHOT.jar /usr/local/hl7receiver/demo.jar
COPY --from=build /home/app/target/classes /usr/local/hl7receiver/classes
COPY --from=build /home/app/target/lib /usr/local/hl7receiver/lib
RUN yum -y install procps
EXPOSE 17000
ENTRYPOINT ["java","-jar","/usr/local/hl7receiver/demo.jar"]

すべての依存関係がビルド時にパッケージ化されていることを確認します。

手順

医療提供者へのHL7 ベースの通知機能をデプロイするには、以下の手順に従います。

ステップ 1 — Network load balancer と AWS Fargate タスクの設定

Site-to-site VPN (または AWS Direct Connect) が設置され、アクティブであると仮定すると、最初に立ち上げるのは、インバウンドの MLLP 接続をターゲットグループに登録されている AWS Fargate コンテナインスタンスで分散して処理するための Network load balancer です。

ロードバランサーとターゲットグループを立ち上げたら、Apache Camel を含むコンテナを実行する AWS Fargate タスクを定義できます。受信トラフィックポートとしてポート 17000 を選択しました。

画像2. AWS Fargate タスクを実行する Amazon ECS クラスターの基本設定。

コンテナタスクの重要な設定項目は、タスクがロードバランサーのターゲットグループに参加するためのヘルスチェックです。今回のケースでは、Apache Camel は Java ベースのアプリケーションなので、以下のチェックを使用しています。

ps -elf | grep java | grep hl7receiver || exit 1

ヘルスチェックに合格すると、コンテナタスクはロードバランサーのターゲットグループに自動登録され、トラフィックのルーティングが開始されます。これらのコンテナは受信したHL7 v2 接続を終端し、HL7メッセージのペイロードを暗号化された Amazon SQS キューに渡します。

ステップ 2 — Amazon SQS キューと AWS Lambda パーサーのセットアップ

次に、AWS Lambda で実行されるパーサーと十分なロジックをPythonで記述します。AWS SQS キューにメッセージが到着するとすぐにトリガーを開始します。パーサーロジックが必要とする追加ライブラリのために、AWS Lambda Layer を作成します。 HL7 解析ライブラリであるhl7apyを含め、zip ファイルとしてパッケージ化します。

画像3.AWS Lambda パーサーは Amazon SQS 送信先として設定します。

通知の送信元メールアドレスを確認するために、環境変数が必要です。これは Amazon SES 内で検証済みのID である必要があります。

画像4.環境変数 sender に、事前に検証されたAmazon SESの送信者アカウントのIDを設定します。

hl7receiver Lambda関数のソースコードは AWS GitHub で入手できます。

hl7receiver 関数がメッセージの処理に複数回 (maxReceiveCount)失敗した場合、Amazon SQS はそのメッセージを事前に設定されたデッドレターキューに送信できます。これらのキューは、消費されなかったメッセージのライフサイクルを処理し、処理が成功しなかった理由を特定し、メッセージを失うことを回避するのに役立ちます。

メッセージがデッドレターキューに送信される前に処理される機会を増やすには、ソースキューの redrive ポリシーの maxReceiveCount を、十分な再試行を可能にするだけの大きさに設定します。

2021 年 12 月 1 日より、AWS は Amazon SQS のデッドレターキュー管理機能を強化し、ボタンをクリックするだけで、失敗したメッセージのサンプルを検査し、再処理のためにソースキューに戻すことがより簡単にできるようになりました。

以下は、前述したLambda 関数で使用できる JSON テストイベントのサンプルです。この関数自体は、Amazon Comprehend Medical や Amazon SES などのサービスを活用します。パーサーの関数が依存するすべてのサービスにアクセスできるように、適切な IAM ロールが設定されていることを確認する必要があります。

{
  "Records": [
    {
      "messageId": "1ff1dfb4-6bf2-4052-af55-cf126d9913e4",
      "receiptHandle": "AQEBxa/5tJUk1mM+m/LdHxBeDhcFOPQPks3TCEu6rzH30Nqaq+4n8ZF76xW5WMKNWroTC5SEnDtsxFUVln50aGPNkp/Zpc5V6XBWcRf1b0Qn4EptzirHDmS6SVsPSgPca4qDpxBcPu08dTx7OyNTwTRxaZtTwwa2mGQC++WIgfT32196pcisY+w/QUVHbd1HdcFQ20NsZQ1BM7MzFevU8zRFOAmT2MMs3+92+H+QiOf4UVm9ievr4N56Z3aKKeGPDb0qlk97k+P45WsB+GFvvZucD07WyqqNkc+UIUpXPUebPrI=",
      "body": "MSH|^~\\&|test|test|testsystem|testfacility|20010101000000||ADT^A04|q123456789t123456789x123456|p|2.3\rEVN|A04|20010101000000|||^jones^michael^^^^^^^current\rPID|1||123456789|0123456789^aa^^jp|martin^steven||19850101000000|m|||123 fake street^suite1^nice town^al^a1b2c3^jp^home^^1234|1234|(555)555-0123^home^jp:1234567|||s|msh|12345678|||||||0|||||n\rPD1|1|||john.smith@dremail.com^smith^john\rOBX|1|st|||42 year old Caucasian female admitted on 7/16/13 from Mercy General to Room 115B. Diagnosis for this admission is s/p PE. Pt admitted for PT/OT/pain control/IV ABT. She had a sitter at the hospital d/t severe agitation and discomfort with the IV line. According to hospital records, two days prior to transfer, her cognitive status improved and she no longer required the sitter. Co-morbid diagnoses include bipolar disorder, chronic fatigue syndrome, diabetes and a-fib. Patient has been taking propanolol 10Mg\r"
    }
  ]
}

Amazon Comprehend Medical が入退院時に病状や薬を抽出できるように、観察結果セグメント (OBX.5) に入院記録を含めます。その目的は、医療提供者にとってできるだけ多くの情報を、有益で伝達しやすい形式にまとめることです。

以下は、上記の例の入院記録 (OBX.5) に基づいた Amazon Comprehend Medical の出力をビジュアル化したものです。

画像5.入院記録 (OBX.5) に基づいた Amazon Comprehend Medical のアウトプットをビジュアル化。

このシナリオでは、Amazon Comprehend Medical によってOBX.5 に含まれるテキスト全体を処理した後、以下のJSON オブジェクトを取得します。

"medications":[
{         "MEDICATION":"PROPANOLOL"       }
],
"conditions":[
{         "MEDICAL_CONDITION":"PE."      },
{         "MEDICAL_CONDITION":"PAIN"      },
{         "MEDICAL_CONDITION":"AGITATION"      },
{         "MEDICAL_CONDITION":"DISCOMFORT"      },
{         "MEDICAL_CONDITION":"BIPOLAR DISORDER"      },
{         "MEDICAL_CONDITION":"CHRONIC FATIGUE SYNDROME"      },
{         "MEDICAL_CONDITION":"DIABETES"      },
{         "MEDICAL_CONDITION":"A-FIB"      }
]
}

フリーテキストから医療データを抽出するとすぐに、データは利用や報告する価値をもちます。

ステップ 3 — Amazon SES の E メール配信

最後に、Amazon SES は医療提供者に通知を配信します。宛先の E メールアドレスは PD1 (訳注：Patient Additional Demographic 1) を想定しており、セキュリティのベストプラクティスとして、既存の MDM ソリューションと照合して、所有権と真正性を検証する必要があります。

Amazon SES を初めてセットアップする場合は、こちらの手順に従ってください。送信元の E メールアドレスを検証する必要があります。

まとめ

患者のイベントに応じた医療提供者への通知は、医療情報の管理者や患者の診療拠点にとって、急速に必要な運用になりつつあります。AWS は、既存の電子カルテ (EMR) ベンダーとの長く大変な交渉や導入サイクルを踏むことなく、これらの要件を満たすためのビルディングブロックを提供します。AWS のコアサービスをいくつか組み合わせることで、患者と医療提供者の双方が、運用上の負担を増やすことなく、効果的な医療情報交換の恩恵を受けることができます。

このブログ記事で紹介した構築パターンとソースコードを利用して、医療提供者へのHL7 ベースの通知を今すぐ導入することができます。AWS の従量課金制モデルとそのサービスの深さと広がりにより、初期設定と実験のコストと労力は、従来の非クラウドネイティブな他の手段よりも大幅に削減されます。このようなイベント駆動型のソリューションは、介護との連携や適切な患者の見守りを迅速に改善することができます。

AWS が世界中の医療およびライフサイエンス分野で行っている取り組みの詳細については、 AWS for Healthと AWS ヘルスケアソリューションをご覧ください。

翻訳は Solutions Architect 今井と窪田が担当しました。原文はこちらです。

ヘルスケアの事例を通して、AWS のクラウドソリューションの詳細をご覧ください。

AWS Public Sector Blog ニュースレターを購読して、公共部門のための AWS のツール、ソリューション、イノベーションの最新情報を受け取るか、お問い合わせください。

AWS Public Sector Blog はあなたの助けを必要としています。このアンケートでは、AWS Public Sector Blog での体験に関する感想を数分で共有いただけます。アンケートからのフィードバックは、読者の好みに沿ったより多くのコンテンツを作成するために使用いたします。

Amazon Web Services ブログ