TCP/IP 接続を介した HL7v2 メッセージの送信

このチュートリアルでは、最小階層プロトコル(MLLP)を使用して TCP/IP 接続で HL7v2 メッセージを送信する手順について説明します。認証者による MLLP イメージの署名を必須にするには、署名付きの MLLP イメージを使用した TCP/IP 接続を介した HL7v2 メッセージの送信の手順に従います。

このチュートリアルでは、GitHub でホストされている、オープンソースの MLLP アダプターを次の環境で実行する手順を説明します。

目標

このチュートリアルを完了すると、以下のことが行えます。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

  • Cloud Healthcare API
  • Google Kubernetes Engine
  • Compute Engine
  • Cloud VPN
  • Pub/Sub

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。 新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

始める前に

このチュートリアルを開始する前に、MLLP と Google Cloud MLLP アダプターを確認して、最小階層プロトコル(MLLP)の概念に関するドキュメントをご覧ください。コンセプト ドキュメントでは、MLLP の概要、ケアシステムが MLLP 接続を介して Cloud Healthcare API との間でメッセージを送受信する方法、MLLP セキュリティの基本について説明しています。

MLLP アダプターを設定する前に、次の手順で Google Cloud プロジェクトを選択または作成し、必要な API を有効にする必要があります。

  1. Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
  2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  3. Google Cloud プロジェクトで課金が有効になっていることを確認します

  4. Cloud Healthcare API, Google Kubernetes Engine, Container Registry, and Pub/Sub API を有効にします。

    API を有効にする

  5. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  6. Google Cloud プロジェクトで課金が有効になっていることを確認します

  7. Cloud Healthcare API, Google Kubernetes Engine, Container Registry, and Pub/Sub API を有効にします。

    API を有効にする

  8. Kubernetes Engine API と関連サービスが有効になるまで待ちます。これには数分かかることがあります。

シェルを選択する

このチュートリアルを完了するには、Cloud Shell またはローカルシェルを使用します。

Google Cloud Shell は、Google Cloud でホストされているリソースを管理するためのシェル環境です。Cloud Shell には、gcloud CLIkubectl ツールがあらかじめインストールされています。gcloud CLI は、Google Cloud への主要なコマンドライン インターフェースを提供しますkubectl は、GKE クラスタに対してコマンドを実行するためのコマンドライン インターフェースを提供します。

ローカルシェルを使用する場合は、gcloud CLI をインストールする必要があります。

Cloud Shell を開くか、ローカルシェルの構成は、次の手順で行います。

Cloud Shell

Cloud Shell の起動は、次の手順で行います。

  1. Google Cloud Console に移動します。

    Google Cloud コンソール

  2. コンソールの右上隅にある [Google Cloud Shell の有効化] ボタン をクリックします。

コンソールの下部にあるフレーム内で Cloud Shell セッションが開きます。このシェルで gcloud コマンドと kubectl コマンドを実行します。

ローカルシェル

gcloud CLI と kubectl ツールをインストールするには、次の手順を完了します。

  1. Google Cloud CLI をインストールして初期化します
  2. アダプターをローカルでテストする場合は、これ以上の手順を行う必要はなく、データセットの作成に進むことができます。アダプターを GKE にデプロイする場合は、次のコマンドを実行して kubectl コマンドライン ツールをインストールします。

    gcloud components install kubectl

データセットの作成

Cloud Healthcare API データセットをまだ作成していない場合は、次の手順でデータセットを作成します。

Console

  1. Google Cloud コンソールで、[データセット] ページに移動します。

    [データセット] に移動

  2. [データセットを作成] をクリックします。
  3. [名前] フィールドに、データセットの識別子を入力します。データセット ID は、次の条件を満たしている必要があります。
    • ロケーション内の一意の ID
    • 次のもので構成される 1 ~ 256 文字の Unicode 文字列。
      • 数字
      • 文字
      • アンダースコア
      • ダッシュ
      • ピリオド
  4. [ローケーション タイプ] で、次のいずれかのロケーション タイプを選択します。
    • リージョン: データセットは、1 つの Google Cloud リージョン内に永続的に存在します。選択したら、[リージョン] フィールドにロケーションを入力するか選択します。
    • マルチリージョン: データセットは複数の Google Cloud リージョンにまたがる 1 つのロケーションに永続的に存在します。選択後、[マルチリージョン] フィールドでマルチリージョン ロケーションを入力または選択します。
  5. [作成] をクリックします。

新しいデータセットがデータセットのリストに表示されます。

gcloud

データセットを作成するには、gcloud healthcare datasets create コマンドを実行します。

gcloud healthcare datasets create DATASET_ID \
    --location=LOCATION

リクエストが成功すると、コマンドから次の出力が返されます。

Create request issued for: [DATASET_ID]
Waiting for operation [OPERATION_ID] to complete...done.
Created dataset [DATASET_ID].

Pub/Sub トピックとサブスクリプションの作成

メッセージが作成または取り込まれたときに通知を受け取るには、HL7v2 ストアで Pub/Sub トピックを構成する必要があります。詳細については、Pub/Sub 通知の構成をご覧ください。

トピックを作成するには、次の手順を行います。

Console

  1. Google Cloud コンソールで Pub/Sub トピックページに移動します。

    Pub/Sub トピックページに移動

  2. [トピックを作成] をクリックします。

  3. URI を使用したトピック名を入力します。

    projects/PROJECT_ID/topics/TOPIC_NAME

    ここで PROJECT_ID Google Cloud プロジェクト ID です。

  4. [作成] をクリックします。

gcloud

トピックを作成するには、gcloud pubsub topics create コマンドを実行します。

gcloud pubsub topics create projects/PROJECT_ID/topics/TOPIC_NAME

リクエストが成功すると、コマンドから次の出力が返されます。

Created topic [projects/PROJECT_ID/topics/TOPIC_NAME].

サブスクリプションの作成は、次の手順で行います。

Console

  1. Google Cloud コンソールで Pub/Sub トピックページに移動します。

    Pub/Sub トピックページに移動

  2. プロジェクトのトピックをクリックします。

  3. [サブスクリプションを作成] をクリックします。

  4. サブスクリプション名を入力します。

    projects/PROJECT_ID/subscriptions/SUBSCRIPTION_NAME

  5. [配信タイプ] を [Pull] のままにして、[作成] をクリックします。

gcloud

サブスクリプションを作成するには、gcloud pubsub subscriptions create コマンドを実行します。

gcloud pubsub subscriptions create SUBSCRIPTION_NAME \
    --topic=projects/PROJECT_ID/topics/TOPIC_NAME

リクエストが成功すると、コマンドから次の出力が返されます。

Created subscription [projects/PROJECT_ID/subscriptions/SUBSCRIPTION_NAME].

Pub/Sub トピックが構成された HL7v2 ストアの作成

HL7v2 ストアを作成し、Pub/Sub トピックで構成します。HL7v2 ストアを作成するには、データセットを作成する必要があります。このチュートリアルでは、HL7v2 ストアと Pub/Sub トピックに同じプロジェクトを使用します。

Pub/Sub トピックが構成された HL7v2 ストアを作成するには、次の手順に従います。

curl

curl -X POST \
    --data "{
      'notificationConfigs': [
        {
          'pubsubTopic': 'projects/PROJECT_ID/topics/PUBSUB_TOPIC',
          'filter': ''
        }
      ]
    }" \
    -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
    -H "Content-Type: application/json; charset=utf-8" \
    "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores?hl7V2StoreId=HL7V2_STORE_ID"

リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID",
  "notificationConfigs": [
    {
      "pubsubTopic": "projects/PROJECT_ID/topics/PUBSUB_TOPIC"
    }
  ]
}

PowerShell

$cred = gcloud auth application-default print-access-token
$headers = @{ Authorization = "Bearer $cred" }

Invoke-WebRequest `
  -Method Post `
  -Headers $headers `
  -ContentType: "application/json; charset=utf-8" `
  -Body "{
      'notificationConfigs': [
        {
          'pubsubTopic': 'projects/PROJECT_ID/topics/PUBSUB_TOPIC',
          'filter': ''
        }
      ]
  }" `
  -Uri "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores?hl7V2StoreId=HL7V2_STORE_ID" | Select-Object -Expand Content

リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

{
  "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID",
  "notificationConfigs": [
    {
      "pubsubTopic": "projects/PROJECT_ID/topics/PUBSUB_TOPIC"
    }
  ]
}

Pub/Sub 権限の構成

HL7v2 メッセージが作成または取り込まれたときに Pub/Sub に通知を送信するには、Cloud Healthcare API で Pub/Sub 権限を構成する必要があります。これはプロジェクトごとに 1 回実施する必要があります。

必要な pubsub.publisher ロールをプロジェクトのサービス アカウントに追加するには、次の手順を実施します。

Console

  1. Google Cloud コンソールの IAM ページで、関連するプロジェクトのサービス アカウントの [ロール] 列にロール Healthcare サービス エージェントと表示されていることを確認します。アカウント名は、service-PROJECT_NUMBER@gcp-sa-healthcare.iam.gserviceaccount.com です。PROJECT_NUMBER を見つける方法については、プロジェクトの識別をご覧ください。

  2. ロールに一致する [継承] 列で、鉛筆アイコンをクリックします。[権限の編集] ペインが開きます。

  3. [別のロールを追加] をクリックし、Pub/Sub パブリッシャーのロールを検索します。

  4. ロールを選択し、[保存] をクリックします。pubsub.publisher ロールがサービス アカウントに追加されます。

gcloud

サービス アカウントの権限を追加するには、gcloud projects add-iam-policy-binding コマンドを実行します。PROJECT_IDPROJECT_NUMBER を見つける方法については、プロジェクトの識別をご覧ください。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-healthcare.iam.gserviceaccount.com \
    --role=roles/pubsub.publisher

事前構築済みの Docker イメージを pull する

MLLP アダプターは、Container Registry 内の事前に構築された Docker イメージでステージングされたコンテナ化アプリケーションです。

次のコマンドを実行して、最新バージョンのイメージを pull します。

docker pull gcr.io/cloud-healthcare-containers/mllp-adapter:latest

MLLP アダプターをローカルでテストする

アダプターをローカルでテストする場合、レシーバー、パブリッシャー、またはその両方として動作するように構成できます。レシーバーとパブリッシャーの構成には次のような主要な違いがあります。

  • アダプタを送信側として実行する場合、外部ソースから HL7v2 メッセージを受信し、messages.ingest を呼び出してメッセージを HL7v2 ストアに取り込み、Pub/Sub 通知を作成します。この通知は、HL7v2 ストアの Pub/Sub トピックに登録されているアプリケーションに送信されます。
  • アダプターがパブリッシャーとして実行されると、messages.create または messages.ingest を使用して HL7v2 ストアで作成または取り込まれた HL7v2 メッセージをリッスンします。メッセージが作成されると、Pub/Sub 通知がアダプターに送信され、アダプターはメッセージを外部レシーバーにパブリッシュします。

以下のセクションでは、レシーバーまたはパブリッシャーとして機能するようアダプターを実行する方法について説明します。

ローカルマシンで MLLP アダプターを実行できることを確認したら、次のGoogle Kubernetes Engine への MLLP アダプターのデプロイに進みます。

MLLP アダプターをレシーバーとしてローカルでテストする

アダプターは、ケアセンターなどの外部ソースから HL7v2 メッセージを受信すると、messages.ingest を呼び出して、HL7v2 メッセージを構成済みの HL7v2 ストアに取り込みます。これは、アダプターのソースコードで確認できます。

アダプターを受信側としてローカルでテストするには、次の手順を実施します。

  1. ビルド済みの Docker イメージを pull したマシンで、次のコマンドを実行します。

    docker run \
        --network=host \
        -v ~/.config:/root/.config \
        gcr.io/cloud-healthcare-containers/mllp-adapter \
        /usr/mllp_adapter/mllp_adapter \
        --hl7_v2_project_id=PROJECT_ID \
        --hl7_v2_location_id=LOCATION \
        --hl7_v2_dataset_id=DATASET_ID \
        --hl7_v2_store_id=HL7V2_STORE_ID \
        --export_stats=false \
        --receiver_ip=0.0.0.0 \
        --port=2575 \
        --api_addr_prefix=https://healthcare.googleapis.com:443/v1 \
        --logtostderr
    

    ここで

    • PROJECT_ID は、HL7v2 ストアを含む Google Cloud プロジェクトの ID です。
    • LOCATION は、HL7v2 ストアが存在するリージョンです。
    • DATASET_ID は、HL7v2 ストアの親データセットの ID です。
    • HL7V2_STORE_ID は、HL7v2 メッセージの送信先となる HL7v2 ストアの ID です。

    前のコマンドを実行すると、アダプターは次のようなメッセージを出力し、ローカルマシンの IP アドレス 127.0.0.1 のポート 2575 で実行を開始します。

    I0000 00:00:00.000000      1 healthapiclient.go:171] Dialing connection to https://healthcare.googleapis.com:443/v1
    I0000 00:00:00.000000      1 mllp_adapter.go:89] Either --pubsub_project_id or --pubsub_subscription is not provided, notifications of the new messages are not read and no outgoing messages will be sent to the target MLLP address.
    

    エラーが発生した場合は、次のトラブルシューティングの手順を行ってください。

  2. アダプターをフォアグラウンド プロセスとして実行しながらテストを続行するには、ローカルマシンで別のターミナルを開きます。

  3. 新しいターミナルで Netcat をインストールするには、次のコマンドを実行します。

    sudo apt install netcat
    
  4. hl7v2-mllp-sample.txt ファイルをダウンロードして、ローカルマシンに保存します。

  5. HL7v2 メッセージをアダプターに送信するには、ファイルをダウンロードしたディレクトリで次のコマンドを実行します。MLLP アダプターは、ローカルホストのポート 2575 でリッスンしています。このコマンドは、MLLP アダプターを介して HL7v2 ストアにメッセージを送信します。

    Linux

    echo -n -e "\x0b$(cat hl7v2-mllp-sample.txt)\x1c\x0d" | nc -q1 localhost 2575 | less
    

    メッセージが HL7v2 ストアに正常に取り込まれた場合、コマンドは次の出力を返します。

    ^KMSH|^~\&|TO_APP|TO_FACILITY|FROM_APP|FROM_FACILITY|19700101010000||ACK|c507a97e-438d-44b0-b236-ea95e5ecbbfb|P|2.5^MMSA|AA|20150503223000^\
    

    この出力により、HL7v2 ストアが AAApplication Accept)レスポンス タイプで応答し、メッセージが検証され、正常に取り込まれたことがわかります。

  6. また、アダプターを実行したターミナルを開いて、メッセージが正常に送信されたことを確認することもできます。出力は次のサンプルようになります。

     I0000 00:00:00.000000       1 healthapiclient.go:171] Dialing connection to https://healthcare.googleapis.com:443/v1
     I0000 00:00:00.000000       1 mllp_adapter.go:89] Either --pubsub_project_id or --pubsub_subscription is not provided, notifications of the new messages are not read and no outgoing messages will be sent to the target MLLP address.
     I0213 00:00:00.000000       1 healthapiclient.go:190] Sending message of size 319.
     I0213 00:00:00.000000       1 healthapiclient.go:223] Message was successfully sent.
    
  7. メッセージは HL7v2 ストアに保存されるため、messages.list を呼び出してメッセージを表示できます。

    curl

    curl -X GET \
         -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
         -H "Content-Type: application/json; charset=utf-8" \
         "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages"
    

    リクエストが成功すると、サーバーはリソースパスでメッセージの ID を返します。

    {
      "hl7V2Messages": [
        {
          "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID"
        }
      ]
    }
    

    PowerShell

    $cred = gcloud auth application-default print-access-token
    $headers = @{ Authorization = "Bearer $cred" }
    
    Invoke-WebRequest `
      -Method Get `
      -Headers $headers `
      -ContentType: "application/json; charset=utf-8" `
      -Uri "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages" | Select-Object -Expand Content
    

    リクエストが成功すると、サーバーはリソースパスでメッセージの ID を返します。

    {
      "hl7V2Messages": [
        {
          "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID"
        }
      ]
    }
    

MLLP アダプターをパブリッシャーとしてローカルでテストする

アダプターをパブリッシャーとしてテストする場合、messages.create または messages.ingest を呼び出してメッセージ ファイルをバイナリデータとして指定します。

アダプターは、messages.createmessages.ingest を介して送信された Pub/Sub メッセージを自動的に確認します。

アダプターは、Pub/Sub メッセージを正常に取得して送信すると通知します。アダプターは Pub/Sub サブスクライバーであるため、これらのメッセージは自動的に確認応答されます。その結果、アダプターにより構成した Pub/Sub サブスクリプションのメッセージ キューから削除されます。

Pub/Sub サブスクリプションから pull し、メッセージがパブリッシュされたことを個別に確認するには、前に作成したトピックに割り当てる 2 番目の Pub/Sub サブスクリプションを作成します。2 番目のサブスクリプションに送信されたメッセージに対しては、アダプターによる自動確認は適用されないため、pull できます。

前に作成したトピックに割り当てる 2 番目の Pub/Sub サブスクリプションの作成は、次の手順で行います。

Console

  1. Google Cloud コンソールで Pub/Sub トピックページに移動します。

    Pub/Sub トピックページに移動

  2. プロジェクトのトピックをクリックします。これは、最初のサブスクリプションの作成で使用したトピックです。

  3. [サブスクリプションを作成] をクリックします。

  4. サブスクリプション名を入力します。

    projects/PROJECT_ID/subscriptions/SECOND_SUBSCRIPTION_NAME

    [配信タイプ] は [Pull] に設定されたままにします。

  5. [作成] をクリックします。

gcloud

前に作成したトピックに割り当てる 2 番目の Pub/Sub サブスクリプションを作成するには、gcloud pubsub subscriptions create コマンドを実行します。

gcloud pubsub subscriptions create SECOND_SUBSCRIPTION_NAME --topic=projects/PROJECT_ID/topics/TOPIC_NAME

リクエストが成功すると、コマンドから次の出力が返されます。

Created subscription [projects/PROJECT_ID/subscriptions/SECOND_SUBSCRIPTION_NAME].

パブリッシャーとしてアダプターをローカルでテストするには、ビルド済みの Docker イメージを取得したマシンで次の手順を実施します。

  1. Netcat をインストールします。

    sudo apt install netcat
    
  2. hl7v2-mllp-ack-sample.txt ファイルをダウンロードして、ローカルマシンに保存します。このファイルには、メッセージをパブリッシュするときにアダプターが応答として必要とする ACK メッセージが含まれています。

  3. ファイルをダウンロードしたディレクトリで、Netcat がポート 2525 で受信接続をリッスンできるようにするには、次のコマンドを実行します。

    Linux

    echo -n -e "\x0b$(cat hl7v2-mllp-ack-sample.txt)\x1c\x0d" | nc -q1 -lv -p 2525 | less
    

    Netcat が起動すると、次のサンプルのような出力メッセージが表示されます。

    listening on [any] 2525 ...
    
  4. Netcat はフォアグラウンドプロセスとして実行されるので、テストを続行するために、ローカルマシンで別のターミナルを開きます。

  5. アダプターを起動するには、新しいターミナルで次のコマンドを実行します。

    docker run \
        --network=host \
        gcr.io/cloud-healthcare-containers/mllp-adapter \
        /usr/mllp_adapter/mllp_adapter \
        --hl7_v2_project_id=PROJECT_ID \
        --hl7_v2_location_id=LOCATION \
        --hl7_v2_dataset_id=DATASET_ID \
        --hl7_v2_store_id=HL7V2_STORE_ID \
        --export_stats=false \
        --receiver_ip=127.0.0.1 --port 2575 \
        --mllp_addr=127.0.0.1:2525 \
        --pubsub_project_id=PROJECT_ID \
        --pubsub_subscription=PUBSUB_SUBSCRIPTION \
        --api_addr_prefix=https://healthcare.googleapis.com:443/v1 \
        --logtostderr
    

    ここで

    • PROJECT_ID は、HL7v2 ストアを含む Google Cloud プロジェクトの ID です。
    • LOCATION は、HL7v2 ストアが存在するリージョンです。
    • DATASET_ID は、HL7v2 ストアの親データセットの ID です。
    • HL7V2_STORE_ID は、HL7v2 メッセージの送信先となる HL7v2 ストアの ID です。
    • PROJECT_ID は、Pub/Sub トピックを含む Google Cloud プロジェクトの ID です。
    • PUBSUB_SUBSCRIPTION は、Pub/Sub トピックに関連付けられた最初に作成したサブスクリプションの名前です。アダプターはこのサブスクリプションのメッセージを消費して自動的に確認応答するため、トピックにパブリッシュされたメッセージを表示するには、前に作成した 2 番目のサブスクリプションからメッセージを pull する必要があります。

    前のコマンドを実行すると、ローカルマシンの 127.0.0.1 IP アドレスのポート 2575 でアダプターの実行が開始されます。

    エラーが発生した場合は、次のトラブルシューティングの手順を行ってください。

    アダプターはフォアグラウンド プロセスとして実行されるため、テストを続行するには、ローカルマシンで別のターミナルを開きます。

  6. hl7v2-sample.json ファイルをダウンロードして、ローカルマシンに保存します。ファイルをダウンロードしたディレクトリで、messages.create メソッドを呼び出して、HL7v2 ストアにメッセージを作成します。

    curl

    HL7v2 メッセージを作成するには、POST リクエストを行い、次の情報を指定します。

    • 親データセットの名前。
    • HL7v2 ストアの名前。
    • メッセージ
    • アクセス トークン

    次のサンプルは、curl を使用した POST リクエストと hl7v2-sample.json というサンプル JSON ファイルを示しています。

    curl -X POST \
         -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
         -H "Content-Type: application/json; charset=utf-8" \
         --data-binary @hl7v2-sample.json \
         "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages"
    

    リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

    {
      "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID",
      "data": "TVNIfF5+XCZ8QXxTRU5EX0ZBQ0lMSVRZfEF8QXwyMDE4MDEwMTAwMDAwMHx8VFlQRV5BfDIwMTgwMTAxMDAwMDAwfFR8MC4wfHx8QUF8fDAwfEFTQ0lJDUVWTnxBMDB8MjAxODAxMDEwNDAwMDANUElEfHwxNAExMTFeXl5eTVJOfDExMTExMTExXl5eXk1STn4xMTExMTExMTExXl5eXk9SR05NQlI=",
      "sendFacility": "SEND_FACILITY",
      "sendTime": "2018-01-01T00:00:00Z",
      "messageType": "TYPE",
      "createTime": "1970-01-01T00:00:00Z",
      "patientIds": [
        {
          "value": "14\u0001111",
          "type": "MRN"
        },
        {
          "value": "11111111",
          "type": "MRN"
        },
        {
          "value": "1111111111",
          "type": "ORGNMBR"
        }
      ]
    }
    

    PowerShell

    HL7v2 メッセージを作成するには、POST リクエストを行い、次の情報を指定します。

    • 親データセットの名前。
    • HL7v2 ストアの名前。
    • メッセージ
    • アクセス トークン

    次のサンプルは、Windows PowerShell を使用した POST リクエストと hl7v2-sample.json というサンプル JSON ファイルを示しています。

    $cred = gcloud auth application-default print-access-token
    $headers = @{ Authorization = "Bearer $cred" }
    
    Invoke-WebRequest `
      -Method Post `
      -Headers $headers `
      -ContentType: "application/json; charset=utf-8" `
      -InFile hl7v2-sample.json `
      -Uri "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages" | Select-Object -Expand Content
    

    リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

    {
      "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID",
      "data": "TVNIfF5+XCZ8QXxTRU5EX0ZBQ0lMSVRZfEF8QXwyMDE4MDEwMTAwMDAwMHx8VFlQRV5BfDIwMTgwMTAxMDAwMDAwfFR8MC4wfHx8QUF8fDAwfEFTQ0lJDUVWTnxBMDB8MjAxODAxMDEwNDAwMDANUElEfHwxNAExMTFeXl5eTVJOfDExMTExMTExXl5eXk1STn4xMTExMTExMTExXl5eXk9SR05NQlI=",
      "sendFacility": "SEND_FACILITY",
      "sendTime": "2018-01-01T00:00:00Z",
      "messageType": "TYPE",
      "createTime": "1970-01-01T00:00:00Z",
      "patientIds": [
        {
          "value": "14\u0001111",
          "type": "MRN"
        },
        {
          "value": "11111111",
          "type": "MRN"
        },
        {
          "value": "1111111111",
          "type": "ORGNMBR"
        }
      ]
    }
    

    メッセージを作成すると、MLLP アダプターは次のレスポンスを返します。

    I0214 00:00:00.000000       1 healthapiclient.go:266] Started to fetch message.
    I0214 00:00:00.000000       1 healthapiclient.go:283] Message was successfully fetched.
    
  7. Netcat を実行したターミナルで、次のサンプルのような出力が表示されます。この出力で、メッセージが公開されたことが示されます。

    connect to [127.0.0.1] from localhost [127.0.0.1] 39522
    ^KMSH|^~\&|A|SEND_FACILITY|A|A|20180101000000||TYPE^A|20180101000000|T|0.0|||AA||00|ASCII^MEVN|A00|20180101040000^MPID||14^A111^^^^MRN|11111111^^^^MRN~1111111111^^^^ORGNMBR^\
    

    これは、メッセージの作成時に受信したレスポンスの data フィールドの値に対応します。hl7v2-sample.json ファイルの data 値と同じです。

  8. アダプターが Pub/Sub トピックにパブリッシュしたメッセージを表示するには、作成した 2 番目の Pub/Sub サブスクリプションで gcloud pubsub subscriptions pull コマンドを実行します。

    gcloud pubsub subscriptions pull --auto-ack SECOND_SUBSCRIPTION
    

    このコマンドは、作成された HL7v2 メッセージに関する次の出力を返します。ATTRIBUTES 列の publish=true 値は、メッセージが Pub/Sub にパブリッシュされたことを示します。

    ┌-----------------------------------------------------------------------------------------------------------------|-----------------|---------------┐
    |                                                               DATA                                              |    MESSAGE_ID   |   ATTRIBUTES  |
    ├-----------------------------------------------------------------------------------------------------------------|-----------------|---------------|
    | projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/HL7V2_MESSAGE_ID | 123456789012345 | msgType=ADT   |
    |                                                                                                                 |                 | publish=true  |
    └-----------------------------------------------------------------------------------------------------------------|-----------------|---------------┘
    

異なる外部レシーバーへのメッセージの公開

複数の Pub/Sub トピックを HL7v2 ストアに構成し、フィルタを使用して異なる Pub/Sub トピックに通知を送信することができます。そして、Pub/Sub トピックごとに MLLP アダプタを実行して、異なる外部レシーバーにメッセージを公開できます。

複数の Pub/Sub トピックと各トピックのフィルタを使用して HL7v2 ストアを構成するには、次の手順を実施します。

  1. 2 つの Pub/Sub トピックと各トピックのサブスクリプションを作成します。詳細については、Pub/Sub トピックとサブスクリプションの作成をご覧ください。

  2. 次のコマンドを実行します。

    curl

    curl -X PATCH \
        -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
        -H "Content-Type: application/json; charset=utf-8" \
        --data "{
          'notificationConfigs': [
              {
                  'pubsubTopic': 'projects/PROJECT_ID/topics/PUBSUB_TOPIC',
                  'filter' : 'sendFacility=\"SEND_FACILITY_1\"'
              },
              {
                  'pubsubTopic': 'projects/PROJECT_ID/topics/SECOND_PUBSUB_TOPIC',
                  'filter': 'sendFacility=\"SEND_FACILITY_2\"'
              }
          ]
        }" "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID?updateMask=notificationConfigs"
    

    リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

    {
      "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID",
      "notificationConfigs": [
        {
          "pubsubTopic": "projects/PROJECT_ID/topics/PUBSUB_TOPIC",
          "filter": "sendFacility=\"SEND_FACILITY_1\""
        },
        {
          "pubsubTopic": "projects/PROJECT_ID/topics/SECOND_PUBSUB_TOPIC",
          "filter": "sendFacility=\"SEND_FACILITY_2\""
        }
      ]
    }
    

    PowerShell

    $cred = gcloud auth application-default print-access-token
    $headers = @{ Authorization = "Bearer $cred" }
    
    Invoke-WebRequest `
      -Method Patch `
      -Headers $headers `
      -ContentType: "application/json; charset=utf-8" `
      -Body "{
          'notificationConfigs': [
            {
              'pubsubTopic' : 'projects/PROJECT_ID/topics/PUBSUB_TOPIC',
              'filter': 'sendFacility=\"SEND_FACILITY_1\"'
            },
            {
              'pubsubTopic' : 'projects/PROJECT_ID/topics/SECOND_PUBSUB_TOPIC',
              'filter' : 'sendFacility=\"SEND_FACILITY_2\"'
            }
          ]
      }" `
      -Uri "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores?hl7V2StoreId=HL7V2_STORE_ID?updateMask=notificationConfigs" | Select-Object -Expand Content
    

    リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

    {
      "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID",
      "notificationConfigs": [
        {
          "pubsubTopic": "projects/PROJECT_ID/topics/PUBSUB_TOPIC",
          "filter": "sendFacility=\"SEND_FACILITY_1\""
        },
        {
          "pubsubTopic": "projects/PROJECT_ID/topics/SECOND_PUBSUB_TOPIC",
          "filter": "sendFacility=\"SEND_FACILITY_2\""
        }
      ]
    }
    

メッセージ ルーティングのテスト

メッセージ ルーティングをテストするには、次のセクションの手順で行います。

最初のレシーバーとアダプターの構成と起動

最初のレシーバーとアダプターを構成して起動するには、次の手順を実施します。

  1. ビルド済みの Docker イメージを pull したマシンで、次のコマンドを実行して Netcat をインストールします。

    sudo apt install netcat
    
  2. hl7v2-mllp-ack-sample.txt をダウンロードします(まだ行っていない場合)。このファイルには、アダプターがメッセージをパブリッシュする際にアダプターがレスポンスとして使用する ACK メッセージが含まれています。

  3. 次のコマンドを実行して、最初のレシーバーにポート 2525 を設定します。

    Linux

    echo -n -e "\x0b$(cat hl7v2-mllp-ack-sample.txt)\x1c\x0d" | nc -q1 -lv -p 2525 | less
    

    Netcat プロセスが起動すると、次の出力が表示されます。

    listening on [any] 2525 ...
    
  4. 最初のアダプターを起動するには、新しいターミナルで次のコマンドを実行します。

    docker run \
        --network=host \
        gcr.io/cloud-healthcare-containers/mllp-adapter \
        /usr/mllp_adapter/mllp_adapter \
        --hl7_v2_project_id=PROJECT_ID \
        --hl7_v2_location_id=LOCATION \
        --hl7_v2_dataset_id=DATASET_ID \
        --hl7_v2_store_id=HL7V2_STORE_ID \
        --export_stats=false \
        --receiver_ip=127.0.0.1 --port 2575 \
        --mllp_addr=127.0.0.1:2525 \
        --pubsub_project_id=PROJECT_ID \
        --pubsub_subscription=PUBSUB_SUBSCRIPTION \
        --api_addr_prefix=https://healthcare.googleapis.com:443/v1 \
        --logtostderr
    

    ここで

    • PROJECT_ID は、HL7v2 ストアを含む Google Cloud プロジェクトの ID です。
    • LOCATION は、HL7v2 ストアが存在するリージョンです。
    • DATASET_ID は、HL7v2 ストアの親データセットの ID です。
    • HL7V2_STORE_ID は、HL7v2 メッセージの送信先となる HL7v2 ストアの ID です。
    • PROJECT_ID は、Pub/Sub トピックを含む Google Cloud プロジェクトの ID です。
    • PUBSUB_SUBSCRIPTION は、最初の Pub/Sub トピックに関連付けられた、最初に作成したサブスクリプションの名前です。アダプターはこのサブスクリプションからのメッセージを消費し、自動的に確認応答します。

    このコマンドを実行すると、ローカルマシンの 127.0.0.1:2575 でアダプターの実行が開始されます。新しいメッセージは、最初の外部レシーバーのポート 2525 に公開されます。

2 番目のレシーバーとアダプターの構成と起動

2 つ目のレシーバーとアダプターを構成して起動するには、次の手順を実施します。

  1. ビルド済みの Docker イメージを pull したマシンで、次のコマンドを実行して Netcat をインストールします。

    sudo apt install netcat
    
  2. hl7v2-mllp-ack-sample.txt をダウンロードします(まだ行っていない場合)。このファイルには、アダプターがメッセージをパブリッシュする際にアダプターがレスポンスとして使用する ACK メッセージが含まれています。

  3. 次のコマンドを実行して、2 番目のレシーバーにポート 2526 を設定します。

    Linux

    echo -n -e "\x0b$(cat hl7v2-mllp-ack-sample.txt)\x1c\x0d" | nc -q1 -lv -p 2526 | less
    

    Netcat プロセスが起動すると、次の出力が表示されます。

    listening on [any] 2526 ...
    
  4. 2 つ目のアダプターを起動するには、新しいターミナルで次のコマンドを実行します。

    docker run \
        --network=host \
        gcr.io/cloud-healthcare-containers/mllp-adapter \
        /usr/mllp_adapter/mllp_adapter \
        --hl7_v2_project_id=PROJECT_ID \
        --hl7_v2_location_id=LOCATION \
        --hl7_v2_dataset_id=DATASET_ID \
        --hl7_v2_store_id=HL7V2_STORE_ID \
        --export_stats=false \
        --receiver_ip=127.0.0.1 --port 2576 \
        --mllp_addr=127.0.0.1:2526 \
        --pubsub_project_id=PROJECT_ID \
        --pubsub_subscription=SECOND_PUBSUB_SUBSCRIPTION \
        --api_addr_prefix=https://healthcare.googleapis.com:443/v1 \
        --logtostderr
    

    ここで

    • PROJECT_ID は、HL7v2 ストアを含む Google Cloud プロジェクトの ID です。
    • LOCATION は、HL7v2 ストアが存在するリージョンです。
    • DATASET_ID は、HL7v2 ストアの親データセットの ID です。
    • HL7V2_STORE_ID は、HL7v2 メッセージの送信先となる HL7v2 ストアの ID です。
    • PROJECT_ID は、Pub/Sub トピックを含む Google Cloud プロジェクトの ID です。
    • SECOND_PUBSUB_SUBSCRIPTION は、2 番目の Pub/Sub トピックに関連付けられた、2 番目に作成したサブスクリプションの名前です。アダプターはこのサブスクリプションからのメッセージを消費し、自動的に確認応答します。

    このコマンドを実行すると、ローカルマシンのポート、127.0.0.1:2576 IP アドレスでアダプターの実行が開始されます。ポート 2526 で 2 番目の外部レシーバーに新しいメッセージを公開します。

最初のレシーバーへのメッセージの公開

最初の外部レシーバーにのみ公開されるメッセージの作成は、次の手順で行います。

  1. hl7v2-sample1.json をダウンロードします。

  2. hl7v2-sample1.json をダウンロードしたディレクトリで、messages.create メソッドを呼び出して、HL7v2 ストアにメッセージを作成します。

    curl

    HL7v2 メッセージを作成するには、POST リクエストを行い、次の情報を指定します。

    • 親データセットの名前。
    • HL7v2 ストアの名前。
    • メッセージ
    • アクセス トークン

    次のサンプルは、curl を使用した POST リクエストとサンプル JSON ファイル hl7v2-sample1.json を示しています。

    curl -X POST \
        -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
        -H "Content-Type: application/json; charset=utf-8" \
        --data-binary @hl7v2-sample1.json \
        "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages"
    

    リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

    {
     "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID",
     "data": "TVNIfF5+XCZ8QXxTRU5EX0ZBQ0lMSVRZXzF8QXxBfDIwMTgwMTAxMDAwMDAwfHxUWVBFXkF8MjAxODAxMDEwMDAwMDB8VHwwLjB8fHxBQXx8MDB8QVNDSUkNRVZOfEEwMHwyMDE4MDEwMTA0MDAwMA1QSUR8fDE0ATExMV5eXl5NUk58MTExMTExMTFeXl5eTVJOfjExMTExMTExMTFeXl5eT1JHTk1CUg==",
     "sendFacility": "SEND_FACILITY_1",
     "sendTime": "2018-01-01T00:00:00Z",
     "messageType": "TYPE",
     "createTime": "1970-01-01T00:00:00Z",
     "patientIds": [
       {
         "value": "14\u0001111",
         "type": "MRN"
       },
       {
         "value": "11111111",
         "type": "MRN"
       },
       {
         "value": "1111111111",
         "type": "ORGNMBR"
       }
     ]
    }
    

    PowerShell

    HL7v2 メッセージを作成するには、POST リクエストを行い、次の情報を指定します。

    • 親データセットの名前。
    • HL7v2 ストアの名前。
    • メッセージ
    • アクセス トークン

    次のサンプルは、Windows PowerShell を使用した POST リクエストと hl7v2-sample1.json というサンプル JSON ファイルを示しています。

    $cred = gcloud auth application-default print-access-token
    $headers = @{ Authorization = "Bearer $cred" }
    
    Invoke-WebRequest `
     -Method Post `
     -Headers $headers `
     -ContentType: "application/json; charset=utf-8" `
     -InFile hl7v2-sample1.json `
     -Uri "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages" | Select-Object -Expand Content
    

    リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

    {
     "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID",
     "data": "TVNIfF5+XCZ8QXxTRU5EX0ZBQ0lMSVRZXzF8QXxBfDIwMTgwMTAxMDAwMDAwfHxUWVBFXkF8MjAxODAxMDEwMDAwMDB8VHwwLjB8fHxBQXx8MDB8QVNDSUkNRVZOfEEwMHwyMDE4MDEwMTA0MDAwMA1QSUR8fDE0ATExMV5eXl5NUk58MTExMTExMTFeXl5eTVJOfjExMTExMTExMTFeXl5eT1JHTk1CUg==",
     "sendFacility": "SEND_FACILITY_1",
     "sendTime": "2018-01-01T00:00:00Z",
     "messageType": "TYPE",
     "createTime": "1970-01-01T00:00:00Z",
     "patientIds": [
       {
         "value": "14\u0001111",
         "type": "MRN"
       },
       {
         "value": "11111111",
         "type": "MRN"
       },
       {
         "value": "1111111111",
         "type": "ORGNMBR"
       }
     ]
    }
    

    このレスポンスでは、sendFacilitySEND_FACILITY_1 に設定されているため、Pub/Sub 通知は最初の Pub/Sub トピックにのみ送信されます。メッセージの作成後、最初の MLLP アダプターは次のレスポンスを返します。

    I0214 00:00:00.000000       1 healthapiclient.go:266] Started to fetch message.
    I0214 00:00:00.000000       1 healthapiclient.go:283] Message was successfully fetched.
    

    2 番目の MLLP アダプターは、2 番目の Pub/Sub トピックに通知が送信されないため、レスポンスを返しません。

    最初の Netcat プロセスを実行したターミナルに、次の出力が表示されます。この出力は、メッセージが公開されたことを示しています。

    connect to [127.0.0.1] from localhost [127.0.0.1] 39522
    ^KMSH|^~\&|A|SEND_FACILITY_1|A|A|20180101000000||TYPE^A|20180101000000|T|0.0|||AA||00|ASCII^MEVN|A00|20180101040000^MPID||14^A111^^^^MRN|11111111^^^^MRN~1111111111^^^^ORGNMBR^\
    

    この出力は、メッセージの作成時に受信したレスポンスの data フィールドの値に対応します。hl7v2-sample1.json ファイルの data 値と同じです。

2 番目のレシーバーへのメッセージの公開

2 番目の外部レシーバーにのみ公開されるメッセージの作成は、次の手順で行います。

  1. ローカルマシンで新しいターミナルを開きます。

  2. 2 番目の外部レシーバーにのみ公開されるメッセージを作成するには、hl7v2-sample2.json をダウンロードします。

  3. hl7v2-sample2.json をダウンロードしたディレクトリで、messages.create メソッドを呼び出して、HL7v2 ストアにメッセージを作成します。

    curl

    HL7v2 メッセージを作成するには、POST リクエストを行い、次の情報を指定します。

    • 親データセットの名前。
    • HL7v2 ストアの名前。
    • メッセージ
    • アクセス トークン

    次のサンプルは、curl を使用した POST リクエストとサンプル JSON ファイル hl7v2-sample2.json を示しています。

    curl -X POST \
        -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
        -H "Content-Type: application/json; charset=utf-8" \
        --data-binary @hl7v2-sample2.json \
        "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages"
    

    リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

    {
     "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID",
     "data": "TVNIfF5+XCZ8QXxTRU5EX0ZBQ0lMSVRZXzJ8QXxBfDIwMTgwMTAxMDAwMDAwfHxUWVBFXkF8MjAxODAxMDEwMDAwMDB8VHwwLjB8fHxBQXx8MDB8QVNDSUkNRVZOfEEwMHwyMDE4MDEwMTA0MDAwMA1QSUR8fDE0ATExMV5eXl5NUk58MTExMTExMTFeXl5eTVJOfjExMTExMTExMTFeXl5eT1JHTk1CUg==",
     "sendFacility": "SEND_FACILITY_2",
     "sendTime": "2018-01-01T00:00:00Z",
     "messageType": "TYPE",
     "createTime": "1970-01-01T00:00:00Z",
     "patientIds": [
       {
         "value": "14\u0001111",
         "type": "MRN"
       },
       {
         "value": "11111111",
         "type": "MRN"
       },
       {
         "value": "1111111111",
         "type": "ORGNMBR"
       }
     ]
    }
    

    PowerShell

    HL7v2 メッセージを作成するには、POST リクエストを行い、次の情報を指定します。

    • 親データセットの名前。
    • HL7v2 ストアの名前。
    • メッセージ
    • アクセス トークン

    次のサンプルは、Windows PowerShell を使用した POST リクエストとサンプル JSON ファイル hl7v2-sample2.json を示しています。

    $cred = gcloud auth application-default print-access-token
    $headers = @{ Authorization = "Bearer $cred" }
    
    Invoke-WebRequest `
     -Method Post `
     -Headers $headers `
     -ContentType: "application/json; charset=utf-8" `
     -InFile hl7v2-sample2.json `
     -Uri "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages" | Select-Object -Expand Content
    

    リクエストが成功すると、サーバーは JSON 形式のレスポンスを返します。

    {
     "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID",
     "data": "TVNIfF5+XCZ8QXxTRU5EX0ZBQ0lMSVRZXzJ8QXxBfDIwMTgwMTAxMDAwMDAwfHxUWVBFXkF8MjAxODAxMDEwMDAwMDB8VHwwLjB8fHxBQXx8MDB8QVNDSUkNRVZOfEEwMHwyMDE4MDEwMTA0MDAwMA1QSUR8fDE0ATExMV5eXl5NUk58MTExMTExMTFeXl5eTVJOfjExMTExMTExMTFeXl5eT1JHTk1CUg==",
     "sendFacility": "SEND_FACILITY_2",
     "sendTime": "2018-01-01T00:00:00Z",
     "messageType": "TYPE",
     "createTime": "1970-01-01T00:00:00Z",
     "patientIds": [
       {
         "value": "14\u0001111",
         "type": "MRN"
       },
       {
         "value": "11111111",
         "type": "MRN"
       },
       {
         "value": "1111111111",
         "type": "ORGNMBR"
       }
     ]
    }
    

    送信ファシリティは SEND_FACILITY_2 であるため、Pub/Sub 通知は 2 番目の Pub/Sub トピックにのみ送信されます。メッセージの作成後、最初の MLLP アダプターはレスポンスを返さず、2 番目の MLLP アダプターは次のレスポンスを返します。

    I0214 00:00:00.000000       1 healthapiclient.go:266] Started to fetch message.
    I0214 00:00:00.000000       1 healthapiclient.go:283] Message was successfully fetched.
    

    2 番目の Netcat プロセスを実行したターミナルで、次の出力が表示されます。この出力は、メッセージが公開されたことを示しています。

    connect to [127.0.0.1] from localhost [127.0.0.1] 39522
    ^KMSH|^~\&|A|SEND_FACILITY_2|A|A|20180101000000||TYPE^A|20180101000000|T|0.0|||AA||00|ASCII^MEVN|A00|20180101040000^MPID||14^A111^^^^MRN|11111111^^^^MRN~1111111111^^^^ORGNMBR^\
    

    この出力は、メッセージの作成時に受信したレスポンスの data フィールドの値に対応します。hl7v2-sample2.json ファイルの data 値と同じです。

MLLP アダプターを Google Kubernetes Engine にデプロイする

ケアセンターから MLLP 経由で HL7v2 メッセージを送信する場合、Google Cloud にデプロイされたアダプターにメッセージを送信し、そこから Cloud Healthcare API に転送する構成が可能です。

MLLP アダプターは、GKE クラスタ上のステートレス アプリケーションとして実行されます。GKE クラスタは、コンテナ化されたアプリケーションを実行するための VM インスタンスのマネージド グループです。ステートレス アプリケーションとは、データやアプリケーションの状態をクラスタや永続ストレージに保存しないアプリケーションです。代わりに、データとアプリケーションの状態はクライアントに保持されるため、ステートレス アプリケーションはスケーラビリティが高くなります。

GKE は Deployment コントローラを使用して、ステートレス アプリケーションを一意でない同一のポッドとしてデプロイします。Deployment では、アプリケーションを実行するポッドの数、実行するコンテナ イメージのバージョン、ポッドにどのラベルを付けるべきかなど、アプリケーションの望ましい状態を管理します。Deployment のポッド仕様を更新することによって、望ましい状態を動的に変更できます。

アダプターをデプロイすると同時に Serviceコントローラを作成し、内部負荷分散を使用してアダプターを Cloud Healthcare API に接続できます。

GKE を初めてお使いの方は、GKE クイックスタートを完了してサービスの仕組みを学習してください。

Pub/Sub API 権限を GKE サービス アカウントに追加する

サービス アカウントを使用した Cloud Platform への認証に関する GKE ドキュメントに記載されているとおり、コンテナ クラスタの各ノードは Compute Engine インスタンスです。したがって、MLLP アダプターがコンテナ クラスタで実行されると、デプロイ先の Compute Engine インスタンスのスコープが自動的に継承されます。

Google Cloud Platform では、「Compute Engine default service account」という名前のサービス アカウントが自動的に作成されます。GKE では、GKE が作成したノードにこのアカウントが関連付けられます。デフォルトのサービス アカウントに他の Cloud Platform API を使用する権限があるかどうかは、プロジェクトの構成方法によって異なります。GKE は、制限されたアクセス スコープを Compute Engine インスタンスに割り当てます。

最良の結果を得るには、デフォルトのサービス アカウントの権限を更新するか、Compute Engine インスタンスに対してより多くのアクセス スコープを割り当てるなどして、GKE で実行されているポッドから他の Google Cloud サービス(Pub/Sub など)を認証しないようにします。代わりに、独自のサービス アカウントを作成します。

必要な Pub/Sub 権限をコンテナ クラスタに付与する必要がありますが、Cloud Monitoring に指標を書き込む権限を付与することもできます。

コンテナクラスタに必要なスコープのみを含む新しいサービス アカウントの作成は、次の手順で行います。

Console

サービス アカウントの作成:

  1. Google Cloud コンソールで [サービス アカウントの作成] ページに移動します。

    [サービス アカウントの作成] に移動

  2. プロジェクトを選択します。

  3. [サービス アカウント名] フィールドに名前を入力します。Google Cloud コンソールは、この名前に基づいて [サービス アカウント ID] フィールドに入力します。

    省略可: [サービス アカウントの説明] フィールドに説明を入力します。

  4. [作成] をクリックします。

  5. [ロールを選択] フィールドをクリックします。

    [すべてのロール] で、[Pub/Sub] > [Pub/Sub サブスクライバー] の順にクリックします。

  6. [別のロールを追加] をクリックし、[ロールを選択] フィールドをクリックします。

    [すべてのロール] で [Cloud Healthcare] > [Healthcare HL7v2 メッセージの取り込み] の順にクリックします。

  7. 省略可: モニタリングを有効にする場合は、[別のロールを追加] をクリックし、[ロールを選択] フィールドをクリックします。

    [すべてのロール] で、[モニタリング] > [モニタリング指標の書き込み] の順にクリックします。

  8. [続行] をクリックします。

  9. [完了] をクリックして、サービス アカウントの作成を完了します。

    ブラウザ ウィンドウは閉じないでください。次の手順でウィンドウを使用します。

サービス アカウント キーを作成します。

  1. Google Cloud コンソールで、作成したサービス アカウントのメールアドレスをクリックします。

  2. [キー] をクリックします。

  3. [鍵を追加]、[新しい鍵を作成] の順にクリックします。

  4. [作成] をクリックします。JSON キーファイルがパソコンにダウンロードされます。

  5. [閉じる] をクリックします。

gcloud

  1. サービス アカウントを作成するには、gcloud iam service-accounts create コマンドを実行します。

    gcloud iam service-accounts create SERVICE_ACCOUNT_NAME
    

    出力はサービス アカウントです。

    Created service account SERVICE_ACCOUNT_NAME.
    
  2. 各ロールをサービス アカウントに付与するには、gcloud projects add-iam-policy-binding コマンドを実行します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
      --role=roles/pubsub.subscriber
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
      --role=roles/healthcare.hl7V2Ingest
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
      --role=roles/monitoring.metricWriter
    

    次のように、更新されたポリシーを出力で確認できます。

    bindings:
        - members:
            - user:SERVICE_ACCOUNT_NAME
            role: roles/pubsub.publisher
        - members:
            - user:SERVICE_ACCOUNT_NAME
            roles/healthcare.hl7V2Ingest
        - members:
            - user:SERVICE_ACCOUNT_NAME
            roles/monitoring.metricWriter
        etag: ETAG
        version: 1
    
  3. サービス アカウント キーを作成するには、gcloud iam service-accounts keys create コマンドを実行します。

    gcloud iam service-accounts keys create ~/FILENAME.json \
       --iam-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
    

    サービス アカウントが作成されると、サービス アカウントの認証情報を含む JSON キーファイルがお使いのパソコンにダウンロードされます。このキーファイルを使用して MLLP アダプターを構成し、クラスタ生成時に --service-account フラグを使用して、Cloud Healthcare API、Pub/Sub API、Cloud Monitoring API を認証します。

    created key [e44da1202f82f8f4bdd9d92bc412d1d8a837fa83] of type [json] as
        [/usr/home/USERNAME/FILENAME.json] for
        [SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com]
    

クラスタの作成

GKE でクラスタを作成するには、gcloud container clusters create コマンドを実行します。

gcloud container clusters create mllp-adapter \
    --zone=COMPUTE_ZONE \
    --service-account CLIENT_EMAIL

ここで

  • COMPUTE_ZONE は、クラスタがデプロイされているゾーンです。ゾーンとは、クラスタとそのリソースが存在するリージョンのおおよその場所を示すものです。たとえば、us-west1-aus-west リージョン内のゾーンです。gcloud config set compute/zone を使用してデフォルト ゾーンを設定した場合は、このフラグの値でデフォルト値がオーバーライドされます。
  • CLIENT_EMAIL はサービス アカウントの識別子です。このメールアドレスは、サービス アカウント キーファイルの "client_email": フィールドにあります。形式は SERVICE_ACCOUNT_NAME@PROJECT_ID .iam.gserviceaccount.com です。

このコマンドでは、次のサンプルのような出力が返されます。

Creating cluster mllp-adapter in COMPUTE_ZONE...
Cluster is being configured...
Cluster is being deployed...
Cluster is being health-checked...
Cluster is being health-checked (master is healthy)...done.
Created [https://container.googleapis.com/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/clusters/mllp-adapter].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/COMPUTE_ZONE/mllp-adapter?project=PROJECT_ID
kubeconfig entry generated for mllp-adapter.
NAME          LOCATION       MASTER_VERSION  MASTER_IP      MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS
mllp-adapter  COMPUTE_ZONE   1.11.7-gke.4    203.0.113.1    n1-standard-1  1.11.7-gke.4  3          RUNNING

クラスタを作成すると、GKE により 3 つの Compute Engine VM インスタンスが作成されます。次のコマンドでインスタンスを一覧表示することで、これを確認できます。

gcloud compute instances list

デプロイを構成する

アプリケーションを GKE にデプロイするときは、Deployment マニフェスト ファイル(通常は YAML ファイル)を使用して Deployment のプロパティを定義します。サンプルについては、Deployment を作成をご覧ください。

  1. 別のターミナルを開きます。

  2. テキストエディタを使用して、次の内容を含む mllp_adapter.yaml というDeployment マニフェスト ファイルを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mllp-adapter-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mllp-adapter
  template:
    metadata:
      labels:
        app: mllp-adapter
    spec:
      containers:
        - name: mllp-adapter
          imagePullPolicy: Always
          image: gcr.io/cloud-healthcare-containers/mllp-adapter
          ports:
            - containerPort: 2575
              protocol: TCP
              name: "port"
          command:
            - "/usr/mllp_adapter/mllp_adapter"
            - "--port=2575"
            - "--hl7_v2_project_id=PROJECT_ID"
            - "--hl7_v2_location_id=LOCATION"
            - "--hl7_v2_dataset_id=DATASET_ID"
            - "--hl7_v2_store_id=HL7V2_STORE_ID"
            - "--api_addr_prefix=https://healthcare.googleapis.com:443/v1"
            - "--logtostderr"
            - "--receiver_ip=0.0.0.0"

ここで

  • PROJECT_ID は、HL7v2 ストアを含む Google Cloud プロジェクトの ID です。
  • LOCATION は、HL7v2 ストアが存在するリージョンです。
  • DATASET_ID は、HL7v2 ストアの親データセットの ID です。
  • HL7V2_STORE_ID は、HL7v2 メッセージの送信先となる HL7v2 ストアの ID です。

Deployment には次のプロパティがあります。

  • spec: replicas: は Deployment が管理する複製ポッドの数です。
  • spec: template: metadata: labels: は各ポッドに付けられたラベルで、Deployment がポッドを管理するために使用します。
  • spec: template: spec:ポッド仕様であり、各ポッドの実行方法を定義します。
  • spec: containers には、各 Pod で実行するコンテナの名前および実行するコンテナ イメージが含まれます。

Deployment 仕様の詳細については、Deployment API リファレンスをご覧ください。

Service の構成

MLLP アダプターをクラスタ外のアプリケーション(ケアセンターなど)からアクセスできるようにするには、内部ロードバランサを構成する必要があります。

VPN を設定していない場合、同じ VPC ネットワークを使用し、同じ Google Cloud リージョンにある限り、アプリケーションは内部ロードバランサを介して MLLP アダプターにアクセスできます。たとえば、同じリージョンおよび同じ VPC ネットワーク上の Compute Engine VM インスタンスにアダプターがアクセスできるようにするには、クラスタの Service に内部ロードバランサを追加します。

Deployment マニフェスト ファイルを作成したディレクトリで、テキスト エディタを使用して mllp_adapter_service.yaml というサービス マニフェスト ファイルを作成し、次の内容を含めます。このファイルは、内部負荷分散を構成するものです。

apiVersion: v1
kind: Service
metadata:
  name: mllp-adapter-service
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  ports:
  - name: port
    port: 2575
    targetPort: 2575
    protocol: TCP
  selector:
    app: mllp-adapter

この Service には次のプロパティがあります。

  • metadata: name:: サービスに付ける名前この場合は mllp-adapter-service です。
  • metadata: annotations: は、内部ロードバランサを構成することを指定するアノテーションです。
  • spec: type: はロードバランサのタイプです。
  • ports: port: は、サービスが同じクラスタ内の他のサービスからトラフィックを受信するポートの指定に使用されます。デフォルトの MLLP ポートの 2575 が使用されます。
  • ports: targetPort: は、サービスが実行されている各ポッドのポートの指定に使用されます。
  • spec: selector: app: は、Service がターゲットとするポッドを指定します。

clusterIPフィールドを使用して)ロードバランサに IP アドレスを指定することもできますが、ロードバランサでメッセージを送信できる独自の IP アドレスを生成することもできます。ここでは、クラスタで IP アドレスを生成できるようにします。このアドレスはこのチュートリアルの後半で使用します。

内部負荷分散の詳細については、GKE のドキュメントをご覧ください。

Service の仕様の詳細については、Service API リファレンスをご覧ください。

Deploymentをデプロイする

アダプターを GKE クラスタにデプロイするには、mllp_adapter.yaml Deployment マニフェスト ファイルを含むディレクトリで、次のコマンドを実行します。

kubectl apply -f mllp_adapter.yaml

このコマンドは、次の出力を返します。

deployment.extensions "mllp-adapter-deployment" created

Deployment を検査する

Deployment を作成したら、kubectl ツールを使用して検査できます。

Deployment の詳細情報を取得するには、次のコマンドを実行します。

kubectl describe deployment mllp-adapter

Deployment によって作成されたポッドを一覧表示するには、次のコマンドを実行します。

kubectl get pods -l app=mllp-adapter

作成されたポッドに関する情報を取得する:

kubectl describe pod POD_NAME

Deployment が成功すると、前のコマンドの最後の部分に次の情報が含まれます。

Events:
  Type    Reason     Age   From                                                  Message
  ----    ------     ----  ----                                                  -------
  Normal  Scheduled  1m    default-scheduler                                     Successfully assigned default/mllp-adapter-deployment-85b46f8-zxw68 to gke-mllp-adapter-default-pool-9c42852d-95sn
  Normal  Pulling    1m    kubelet, gke-mllp-adapter-default-pool-9c42852d-95sn  pulling image "gcr.io/cloud-healthcare-containers/mllp-adapter"
  Normal  Pulled     1m    kubelet, gke-mllp-adapter-default-pool-9c42852d-95sn  Successfully pulled image "gcr.io/cloud-healthcare-containers/mllp-adapter"
  Normal  Created    1m    kubelet, gke-mllp-adapter-default-pool-9c42852d-95sn  Created container
  Normal  Started    1m    kubelet, gke-mllp-adapter-default-pool-9c42852d-95sn  Started container

サービスの Deployment と内部ロードバランサの作成

内部ロードバランサを作成するには、mllp_adapter_service.yaml Service マニフェスト ファイルを含むディレクトリで、次のコマンドを実行します。

kubectl apply -f mllp_adapter_service.yaml

このコマンドは、次の出力を返します。

service "mllp-adapter-service" created

Service を検査する

Service を作成したら、Service が正常に構成されていることを確認します。

次のコマンドを実行して、内部ロードバランサを検査します。

kubectl describe service mllp-adapter-service

このコマンドの出力は、次のようになります。

Name:                     mllp-adapter-service
Namespace:                default
Labels:                   <none>
Annotations:              cloud.google.com/load-balancer-type=Internal
                          kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"cloud.google.com/load-balancer-type":"Internal"},"name":"mllp-adapter-service","namespa...
Selector:                 app=mllp-adapter
Type:                     LoadBalancer
IP:                       203.0.113.1
LoadBalancer Ingress:     203.0.113.1
Port:                     port  2575/TCP
TargetPort:               2575/TCP
NodePort:                 port  30660/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason                Age   From                Message
  ----    ------                ----  ----                -------
  Normal  EnsuringLoadBalancer  1m    service-controller  Ensuring load balancer
  Normal  EnsuredLoadBalancer   1m    service-controller  Ensured load balancer

LoadBalancer Ingress の IP アドレスの入力には 1 分ほどかかることがあります。この IP アドレスと 2575 ポートを使用して、次の手順でクラスタの外部から Service にアクセスします。

Compute Engine VM の作成とメッセージの送信

このチュートリアルの前半では、MLLP アダプタをローカルでテストし、HL7v2 メッセージを HL7v2 ストアに送信しましたが、ここでは Compute Engine VM から GKE 上で実行されている MLLP アダプタにメッセージを送信します。 その後、メッセージは HL7v2 ストアに転送されます。

新しいインスタンスから GKE クラスタにリクエストを送信するには、インスタンスと既存のインスタンスが同じリージョンにあり、同じ VPC ネットワークを使用している必要があります。

このセクションの最後では、Pub/Sub トピックに公開された通知と、HL7v2 ストアの HL7v2 メッセージの一覧を表示します。これらのタスクを行うには、Compute Engine VM インスタンスに権限を付与する必要があります。インスタンスを作成する前に、以下の手順に従い必要な権限を持つ新しいサービス アカウントを作成します。

Console

サービス アカウントの作成:

  1. Google Cloud コンソールで [サービス アカウントの作成] ページに移動します。

    [サービス アカウントの作成] に移動

  2. プロジェクトを選択します。

  3. [サービス アカウント名] フィールドに名前を入力します。Google Cloud コンソールは、この名前に基づいて [サービス アカウント ID] フィールドに入力します。

    省略可: [サービス アカウントの説明] フィールドに説明を入力します。

  4. [作成] をクリックします。

  5. [ロールを選択] フィールドをクリックします。

    [すべてのロール] で、[Pub/Sub] > [Pub/Sub サブスクライバー] の順にクリックします。

  6. [別のロールを追加] をクリックし、[ロールを選択] フィールドをクリックします。

    [すべてのロール] で [Cloud Healthcare] > [Healthcare HL7v2 Message Consumer] の順にクリックします。

  7. [続行] をクリックします。

  8. [完了] をクリックして、サービス アカウントの作成を完了します。

    ブラウザ ウィンドウは閉じないでください。次の手順でウィンドウを使用します。

サービス アカウント キーを作成します。

  1. Google Cloud コンソールで、作成したサービス アカウントのメールアドレスをクリックします。

  2. [キー] をクリックします。

  3. [鍵を追加]、[新しい鍵を作成] の順にクリックします。

  4. [作成] をクリックします。JSON キーファイルがパソコンにダウンロードされます。

  5. [閉じる] をクリックします。

gcloud

  1. サービス アカウントを作成するには、gcloud iam service-accounts create コマンドを実行します。

    gcloud iam service-accounts create SERVICE_ACCOUNT_NAME
    

    出力はサービス アカウントです。

    Created service account SERVICE_ACCOUNT_NAME.
    
  2. 各ロールをサービス アカウントに付与するには、gcloud projects add-iam-policy-binding コマンドを実行します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
      --role=roles/pubsub.publisher
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
      --role=roles/healthcare.hl7V2Consumer
    

    次のように、更新されたポリシーを出力で確認できます。

    bindings:
        - members:
            - user:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
            role: roles/pubsub.publisher
        - members:
            - user:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
            roles/healthcare.hl7V2Consumer
        etag: ETAG
        version: 1
    
  3. サービス アカウント キーを作成するには、gcloud iam service-accounts keys create コマンドを実行します。

    gcloud iam service-accounts keys create ~/FILENAME.json \
       --iam-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
    

    サービス アカウントが作成されると、サービス アカウントの認証情報を含む JSON キーファイルがお使いのパソコンにダウンロードされます。

次の手順は、Compute Engine で Linux 仮想マシン インスタンスを作成する方法を示しています。

Console

  1. Google Cloud コンソールで、[VM インスタンス] ページに移動します。

    [VM インスタンス] ページに移動

  2. [インスタンスを作成] をクリックします。

  3. インスタンスに対して、クラスタを作成したときに選択したゾーンと一致するリージョンゾーンを選択します。たとえば、クラスタの作成時に COMPUTE_ZONE として us-central1-a を使用した場合、インスタンスの作成画面で、リージョンには us-central1 (Iowa) を、ゾーンには us-central1-a を選択します。

  4. [ブートディスク] セクションで [変更] をクリックし、ブートディスクの構成を開始します。

  5. [公開イメージ] タブで、Debian オペレーティング システムのバージョン9を選択します。

  6. [選択] をクリックします。

  7. [ID と API アクセス] セクションで、作成したサービス アカウントを選択します。

  8. [ファイアウォール] セクションで [HTTP トラフィックを許可する] を選択します。

  9. [作成] をクリックしてインスタンスを作成します。

gcloud

コンピューティング インスタンスを作成するには、次のオプションを使用して gcloud compute instances create メソッドを実行します。

  • クラスタの作成時に選択した ZONE
  • HTTP トラフィックを許可する http-server タグ
  • 作成した SERVICE_ACCOUNT
gcloud compute instances create COMPUTE_NAME \
   --project=PROJECT_ID \
   --zone=ZONE \
   --image-family=debian-9 \
   --image-project=debian-cloud \
   --tags=http-server \
   --service-account=SERVICE_ACCOUNT

出力は次のサンプルのようになります。

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/COMPUTE_NAME].
NAME          ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
COMPUTE_NAME  ZONE           n1-standard-1               INTERNAL_IP  EXTERNAL_IP    RUNNING

インスタンスが起動するまで、しばらくお待ちください。インスタンスが起動すると、[VM インスタンス] ページに緑色のステータス アイコンが表示されます。

デフォルトでは、クラスタで使用するのと同じデフォルトの VPC ネットワークをインスタンスで使用します。これは、インスタンスからクラスタにトラフィックを送信できることを意味します。

インスタンスへの接続は、次の手順で行います。

Console

  1. Google Cloud コンソールで、[VM インスタンス] ページに移動します。

    [VM インスタンス] ページに移動

  2. 仮想マシン インスタンスのリストで、作成したインスタンスの行にある [SSH] をクリックします。

gcloud

インスタンスに接続するには、gcloud compute ssh コマンドを実行します。

gcloud compute ssh INSTANCE_NAME \
    --project PROJECT_ID \
    --zone ZONE

Linux インスタンスとのやり取りに使用するターミナル ウィンドウが用意されています。

  1. ターミナル ウィンドウで、Netcat をインストールします。

    sudo apt install netcat
    
  2. hl7v2-mllp-sample.txt ファイルをダウンロードしてインスタンスに保存します。ファイルで使用されるエンコードとセグメント ターミネータについては、HL7v2 メッセージ セグメント区切り文字とエンコードをご覧ください。

  3. MLLP アダプターを介して HL7v2 メッセージを HL7v2 ストアに送信するには、ファイルをダウンロードしたディレクトリで次のコマンドを実行します。Service を検査したときに表示された LoadBalancer Ingress の値を使用します。

    echo -n -e "\x0b$(cat hl7v2-mllp-sample.txt)\x1c\x0d" | nc LOAD_BALANCER_INGRESS_IP_ADDRESS 2575
    

    このコマンドを実行すると、MLLP アダプタを介して HL7v2 ストアにメッセージが送信されます。メッセージが HL7v2 ストアに正常に取り込まれた場合、コマンドは次の出力を返します。

    MSA|AA|20150503223000|ILITY|FROM_APP|FROM_FACILITY|20190312162410||ACK|f4c59243-19c2-4373-bea0-39c1b2ba616b|P|2.5
    

    この出力により、HL7v2 ストアが AAApplication Accept)レスポンス タイプで応答し、メッセージが検証され、正常に取り込まれたことがわかります。

  4. Pub/Sub トピックにパブリッシュされたメッセージを表示するには、gcloud pubsub subscriptions pull コマンドを実行します。

    gcloud pubsub subscriptions pull --auto-ack PUBSUB_SUBSCRIPTION
    

    このコマンドは、取り込まれた HL7v2 メッセージに関する次の出力を返します。

    ┌-----------------------------------------------------------------------------------------------------------------|-----------------|---------------┐
    |                                                               DATA                                              |    MESSAGE_ID   |   ATTRIBUTES  |
    ├-----------------------------------------------------------------------------------------------------------------|-----------------|---------------|
    | projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/HL7V2_MESSAGE_ID | 123456789012345 | msgType=ADT   |
    └-----------------------------------------------------------------------------------------------------------------|-----------------|---------------┘
    
  5. また、HL7v2 ストア内のメッセージをリスト表示して、メッセージが追加されたかどうかを確認することもできます。

    curl

    curl -X GET \
         -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
         -H "Content-Type: application/json; charset=utf-8" \
         "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages"
    

    リクエストが成功すると、サーバーはリソースパスでメッセージの ID を返します。

    {
      "hl7V2Messages": [
        {
          "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID"
        }
      ]
    }
    

    PowerShell

    $cred = gcloud auth application-default print-access-token
    $headers = @{ Authorization = "Bearer $cred" }
    
    Invoke-WebRequest `
      -Method Get `
      -Headers $headers `
      -ContentType: "application/json; charset=utf-8" `
      -Uri "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages" | Select-Object -Expand Content
    

    リクエストが成功すると、サーバーはリソースパスでメッセージの ID を返します。

    {
      "hl7V2Messages": [
        {
          "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID"
        }
      ]
    }
    

このセクションを完了すると、MLLP アダプターが正常に GKE にデプロイされ、リモート インスタンスからアダプターおよび Cloud Healthcare API に HL7v2 メッセージが送信されます。

このチュートリアルの残りの部分では、「オンプレミス」インスタンスとして機能する Compute Engine インスタンスとアダプターの間で VPN を構成して、送信された HL7v2 メッセージを安全に暗号化する方法を学びます。

VPN の構成

VPN を使用すると、公共ネットワーク(インターネットなど)で HL7v2 メッセージを送信するプライベート ネットワークを拡張できます。VPN を使用すると、MLLP アダプターを介してケアセンターから Google Cloud にメッセージを送信できます。このフローでのシステムは、単一のプライベート ネットワーク上にあるかのように機能します。

VPN を使用した MLLP 接続を保護する方法には、以下の 2 つがあります。

  • Cloud VPN の使用
  • Docker のエンドツーエンド VPN ソリューションの使用

Cloud VPN を構成する

Cloud VPN は、IPSec VPN 接続を介してオンプレミス ネットワークを Google Cloud Virtual Private Cloud(VPC)ネットワークに安全に接続します。2 つのネットワーク間のトラフィックは一方の VPN ゲートウェイで暗号化され、もう一方の VPN ゲートウェイで復号されます。これにより、インターネットやケアセンター ネットワークを経由するデータを保護できます。

このチュートリアルでは、設定する各 VPN ゲートウェイは、異なる Google Cloud リージョンの異なるカスタム ネットワークとサブネットにあります。

us-central1 で構成された VPN ゲートウェイは Google Cloud 側の Cloud VPN ゲートウェイとして機能し、europe-west1 の Cloud VPN ゲートウェイは「オンプレミス」ゲートウェイをシミュレートします。

名前とアドレスのリファレンス

このチュートリアルでは、次の名前と IP アドレスを使用しています。

Google Cloud 側

  • ネットワーク名: cloud-vpn-network
  • サブネット名: subnet-us-central-10-0-1
  • リージョン: us-central1
  • サブネット範囲: 10.0.1.0/24
  • 外部 IP アドレス名: cloud-vpn-ip
  • VPN ゲートウェイの名前: vpn-us-central
  • VPN トンネル名: vpn-us-central-tunnel-1

「オンプレミス」側

  • ネットワーク名: on-prem-vpn-network
  • サブネット名: subnet-europe-west-10-0-2
  • リージョン: europe-west1
  • サブネット範囲: 10.0.2.0/24
  • 外部 IP アドレス名: on-prem-vpn-ip
  • VPN ゲートウェイの名前: vpn-europe-west
  • VPN トンネル名: vpn-europe-west-tunnel-1

カスタム VPC ネットワークとサブネットの作成

Cloud VPN を構成する最初のステップは、2 つのVPC ネットワークを作成することです。on-prem-vpn-network という 1 つのネットワークが「オンプレミス」環境で構成され、on-prem-instance という Compute Engine VM インスタンスで実行されます。cloud-vpn-network と呼ばれるもう 1 つのネットワークは、MLLP アダプターを実行する GKE クラスタで使用されます。on-prem-instance VM に接続し、MLLP アダプターの内部ロードバランサを介して cloud-vpn-network ネットワークで実行されている MLLP アダプターに HL7v2 メッセージを送信します。

次の手順を実行して、2 つのカスタム VPC ネットワークとそのサブネットを作成します。

  1. 最初の VPC ネットワーク cloud-vpn-network を作成するには、次のコマンドを実行します。

    gcloud compute networks create cloud-vpn-network \
       --project=PROJECT_ID \
       --subnet-mode=custom
    
  2. cloud-vpn-network ネットワークの subnet-us-central-10-0-1 サブネットを作成するには、次のコマンドを実行します。

    gcloud compute networks subnets create subnet-us-central-10-0-1 \
       --project=PROJECT_ID \
       --region=us-central1 \
       --network=cloud-vpn-network \
       --range=10.0.1.0/24
    
  3. 次のコマンドを実行して、on-prem-vpn-network VPC ネットワークを作成します。

    gcloud compute networks create on-prem-vpn-network \
       --project=PROJECT_ID \
       --subnet-mode=custom
    
  4. on-prem-vpn-network VPC ネットワークの subnet-europe-west-10-0-2 サブネットを作成するには、次のコマンドを実行します。

    gcloud compute networks subnets create subnet-europe-west-10-0-2 \
       --project=PROJECT_ID \
       --region=europe-west1 \
       --network=on-prem-vpn-network \
       --range=10.0.2.0/24
    

外部 IP アドレスの作成

VPN ゲートウェイを作成する前に、次の手順を行って、各ゲートウェイの外部 IP アドレスを予約します。

  1. cloud-vpn-ip アドレス用にリージョン外部(静的)IP アドレスを予約するには、次のコマンドを実行します。

    gcloud compute addresses create cloud-vpn-ip \
       --project=PROJECT_ID \
       --region=us-central1
    
  2. on-prem-vpn-ip アドレス用にリージョン外部(静的)IP アドレスを予約するには、次のコマンドを実行します。

    gcloud compute addresses create on-prem-vpn-ip \
       --project=PROJECT_ID \
       --region=europe-west1
    
  3. 外部 IP アドレスをメモして、次のセクションで VPN ゲートウェイを構成する際に使用できるようにします。次のコマンドを実行して、外部 IP アドレスを取得します。

    Cloud VPN の IP アドレス:

    gcloud compute addresses describe cloud-vpn-ip  \
       --project PROJECT_ID \
       --region us-central1 \
       --format='flattened(address)'
    

    「オンプレミス」の VPN IP アドレス:

    gcloud compute addresses describe on-prem-vpn-ip \
       --project PROJECT_ID \
       --region europe-west1 \
       --format='flattened(address)'
    

    このコマンドでは、次のような出力が返されます。

    address: 203.0.113.1
    

VPN ゲートウェイ、トンネル、ルートの作成

Cloud VPN の VPN ゲートウェイ、トンネル、ルートの作成は、次の手順で行います。

  1. 強力な事前共有鍵の生成の手順に沿って、暗号的に強力な事前共有鍵(共有シークレット)を作成します。この鍵は、このセクションでは SHARED_SECRET として参照されます。

  2. ターゲット VPN ゲートウェイ オブジェクトを作成するには、次のコマンドを実行します。

    gcloud compute target-vpn-gateways create vpn-us-central \
       --project PROJECT_ID \
       --region us-central1 \
       --network cloud-vpn-network
    
  3. 3 つの転送ルールを作成するには、次のコマンドを実行します。CLOUD_VPN_EXTERNAL_ADDRESS 変数は、前のセクションのCloud VPN IP アドレスの値に置き換えます。

    ESP(IPSec)トラフィックをゲートウェイに送信する

    gcloud compute forwarding-rules create vpn-us-central-rule-esp \
        --project PROJECT_ID \
        --region us-central1 \
        --address CLOUD_VPN_EXTERNAL_ADDRESS \
        --ip-protocol ESP \
        --target-vpn-gateway vpn-us-central
    

    UDP 500 トラフィックをゲートウェイに送信する

    gcloud compute forwarding-rules create vpn-us-central-rule-udp500 \
        --project PROJECT_ID \
        --region us-central1 \
        --address CLOUD_VPN_EXTERNAL_ADDRESS \
        --ip-protocol UDP \
        --ports 500 \
        --target-vpn-gateway vpn-us-central
    

    UDP 4500 トラフィックをゲートウェイに送信する

    gcloud compute forwarding-rules create vpn-us-central-rule-udp4500 \
        --project PROJECT_ID \
        --region us-central1 \
        --address CLOUD_VPN_EXTERNAL_ADDRESS \
        --ip-protocol UDP \
        --ports 4500 \
        --target-vpn-gateway vpn-us-central
    
  4. Cloud VPN ゲートウェイへのトンネルを作成するには、次のコマンドを実行します。ON_PREM_VPN_IP は、前のセクションの「オンプレミス」VPN IP アドレスの値に置き換えます。

    gcloud compute vpn-tunnels create vpn-us-central-tunnel-1 \
        --project PROJECT_ID \
        --region us-central1 \
        --peer-address ON_PREM_VPN_IP \
        --shared-secret SHARED_SECRET \
        --ike-version 2 \
        --local-traffic-selector 0.0.0.0/0 \
        --target-vpn-gateway vpn-us-central
    
  5. 10.0.2.0/24 への静的ルートを作成するには、次のコマンドを実行します。

    gcloud compute routes create "vpn-us-central-tunnel-1-route-1" \
       --project PROJECT_ID \
       --network "cloud-vpn-network" \
       --next-hop-vpn-tunnel "vpn-us-central-tunnel-1" \
       --next-hop-vpn-tunnel-region "us-central1" \
       --destination-range "10.0.2.0/24"
    

「オンプレミス」VPN の VPN ゲートウェイ、トンネル、ルートの作成は、次の手順で行います。

  1. ターゲット VPN ゲートウェイ オブジェクトを作成するには、次のコマンドを実行します。

    gcloud compute target-vpn-gateways create "vpn-europe-west" \
       --project PROJECT_ID \
       --region "europe-west1" \
       --network "on-prem-vpn-network"
    
  2. 3 つの転送ルールを作成するには、次のコマンドを実行します。ON_PREMISES_VPN_EXTERNAL_ADDRESS 変数は、前のセクションの[オンプレミス] VPN IP アドレスの値に置き換えます。

    ESP(IPSec)トラフィックをゲートウェイに送信する

    gcloud compute forwarding-rules create vpn-europe-west-rule-esp \
        --project PROJECT_ID \
        --region europe-west1 \
        --address ON_PREMISES_VPN_EXTERNAL_ADDRESS \
        --ip-protocol ESP \
        --target-vpn-gateway vpn-europe-west
    

    UDP 500 トラフィックをゲートウェイに送信する

    gcloud compute forwarding-rules create vpn-europe-west-rule-udp500 \
        --project PROJECT_ID \
        --region europe-west1 \
        --address ON_PREMISES_VPN_EXTERNAL_ADDRESS \
        --ip-protocol UDP \
        --ports 500 \
        --target-vpn-gateway vpn-europe-west
    

    UDP 4500 トラフィックをゲートウェイに送信する

    gcloud compute forwarding-rules create vpn-europe-west-rule-udp4500 \
         --project PROJECT_ID \
         --region europe-west1 \
         --address ON_PREMISES_VPN_EXTERNAL_ADDRESS \
         --ip-protocol UDP \
         --ports 4500 \
         --target-vpn-gateway vpn-europe-west
    
  3. 「オンプレミス」ゲートウェイへのトンネルを作成するには、次のコマンドを実行します。

    gcloud compute vpn-tunnels create vpn-europe-west-tunnel-1 \
       --project PROJECT_ID \
       --region europe-west1 \
       --peer-address CLOUD_VPN_IP \
       --shared-secret SHARED_SECRET \
       --ike-version 2 \
       --local-traffic-selector 0.0.0.0/0 \
       --target-vpn-gateway vpn-europe-west
    
  4. 10.0.1.0/24 への静的ルートを作成するには、次のコマンドを実行します。

    gcloud compute routes create "vpn-europe-west-tunnel-1-route-1" \
       --project PROJECT_ID \
       --network "on-prem-vpn-network" \
       --next-hop-vpn-tunnel "vpn-europe-west-tunnel-1" \
       --next-hop-vpn-tunnel-region "europe-west1" \
       --destination-range "10.0.1.0/24"
    

これで、Cloud VPN と「オンプレミス」ゲートウェイが作成され、そのトンネルが開通しました。VPN ゲートウェイは、ゲートウェイ間のトラフィックを許可するファイアウォールルールを作成するまで接続されません。

ファイアウォール ルールの作成

ファイアウォール ルールは、VPN トンネルのそれぞれの側で作成する必要があります。ファイアウォール ルールを作成すると、VPN トンネルの一方の側のサブネットから他方の側のサブネットへと、TCP、UDP、ICMP のすべてのトラフィックを送ることができます。

  1. Cloud VPN サブネットのファイアウォール ルールを作成するには、次のコマンドを実行します。

    gcloud compute firewall-rules create allow-tcp-udp-icmp-cloud-vpn \
       --project=PROJECT_ID \
       --direction=INGRESS \
       --priority=1000 \
       --network=cloud-vpn-network \
       --action=ALLOW \
       --rules=tcp,udp,icmp \
       --source-ranges=10.0.2.0/24
    
  2. 「オンプレミス」サブネットのファイアウォール ルールを作成するには、次のコマンドを実行します。

    gcloud compute firewall-rules create allow-tcp-udp-icmp-on-prem-vpn \
       --project=PROJECT_ID \
       --direction=INGRESS \
       --priority=1000 \
       --network=on-prem-vpn-network \
       --action=ALLOW \
       --rules=tcp,udp,icmp \
       --source-ranges=10.0.1.0/24
    
  3. 次のコマンドを実行して、ポート 22 で VM インスタンスに SSH 接続できるファイアウォール ルールを作成します。

    gcloud compute firewall-rules create on-prem-vpn-allow-ssh \
       --project=PROJECT_ID \
       --direction=INGRESS \
       --priority=1000 \
       --network=on-prem-vpn-network \
       --action=ALLOW \
       --rules=tcp:22 \
       --source-ranges=0.0.0.0/0
    

VPN トンネルのステータスの確認

トンネルが稼働していることを確認するには、次の手順を行います。

  1. Google Cloud コンソールの [VPN] ページに移動します。

    [VPN] ページに移動

  2. [Google VPN トンネル] タブをクリックします。

  3. 各トンネルの [ステータス] フィールドで、緑色のチェックマークと [確立済み] を探します。これらの項目がある場合、ゲートウェイはトンネルをネゴシエートしました。数分経っても表示されない場合は、トラブルシューティングを確認してください。

    VPN トンネルに関する追加のロギング情報については、トラブルシューティング ページVPN ログの確認をご覧ください。たとえば、破棄されたパケット、トンネルのステータス、受信バイト、送信バイトに関する指標を確認できます。

必要なゲートウェイ、トンネル、ファイアウォール ルールを使用して Cloud VPN が正常に構成されたので、「オンプレミス」VM インスタンスと GKE で実行される MLLP アダプターの間に安全な接続を作成できます。

GKE と Cloud VPN への Deployment の組み合わせ

このチュートリアルの前半では、MLLP アダプタをローカルでテストし、VPN 以外の接続を介して MLLP アダプタに HL7v2 メッセージを送信しましたが、ここでは Cloud VPN を使用する安全な接続を介して Compute Engine VM から GKE で実行されている MLLP アダプタにメッセージを送信します。その後、メッセージは HL7v2 ストアに転送されます。

Deployment の再作成

まず、Cloud VPN の構成で構成した設定をクラスタが使用できるように、GKE に Deployment を再作成します。

  1. 作成した mllp-adapter クラスタを削除するには、gcloud container clusters delete コマンドを実行します。クラスタの作成時に使用した COMPUTE_ZONE 値を入力します。

    gcloud container clusters delete mllp-adapter --zone=COMPUTE_ZONE
    
  2. Kubernetes Engine への MLLP アダプターのデプロイの手順に従います。ただし、GKE でクラスタを作成するときに、カスタム VPN ネットワークとサブネットの作成で作成した cloud-vpn-network ネットワークと subnet-us-central-10-0-1 サブネットを追加します。

    クラスタ作成コマンドが次のようになっていることを確認します。

    gcloud container clusters create mllp-adapter \
       --zone=COMPUTE_ZONE \
       --service-account=CLIENT_EMAIL \
       --network=cloud-vpn-network \
       --subnetwork=subnet-us-central-10-0-1
    

    ここで

    • COMPUTE_ZONE は、クラスタがデプロイされているゾーンです。前のセクションで Cloud VPN を構成したときに、us-central1 を使用するよう「Google Cloud 側」のネットワークを設定しました。この「Google Cloud 側」ネットワークが、GKE クラスタが実行されるネットワークです。us-central1us-central1-cus-central1-aus-central1-fus-central1-b のいずれかのゾーンを使用します。

    • CLIENT_EMAIL はサービス アカウントの識別子です。これは、サービス アカウント キーファイルの "client_email": フィールドにあります。形式は、SERVICE_ACCOUNT_NAME@PROJECT_ID .iam.gserviceaccount.com です。

ネットワーク設定がある新しい Compute Engine VM を作成する

次の手順は、Google Cloud コンソールを使用して Compute Engine で Linux 仮想マシン インスタンスを作成する方法を示しています。作成した Compute Engine VM とは異なり、この VM は「オンプレミス」側のネットワーク設定を使用して、VPN 経由で GKE クラスタと通信します。

Console

  1. Google Cloud コンソールで、[VM インスタンス] ページに移動します。

    [VM インスタンス] ページに移動

  2. [インスタンスを作成] をクリックします。

  3. インスタンスに対して、「オンプレミス側」のネットワーク設定、すなわちリージョンeurope-west1 (Belgium)ゾーンeurope-west1-b、と一致する、リージョンゾーンを選択します。

  4. [ブートディスク] セクションで [変更] をクリックし、ブートディスクの構成を開始します。

  5. [公開イメージ] タブで、Debian オペレーティング システムのバージョン 9 を選択します。

  6. [選択] をクリックします。

  7. [ID と API アクセス] セクションで、作成したサービス アカウントを選択します。

  8. [ファイアウォール] セクションで [HTTP トラフィックを許可する] を選択します。

  9. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] セクションを展開します。

  10. [ネットワーキング] タブの [ネットワークインターフェース] で、「オンプレミス」側ネットワーク設定のネットワークの詳細を指定します。

    1. [ネットワーク] フィールドで [on-prem-vpn-network] を選択します。
    2. [サブネットワーク] フィールドで、subnet-europe-west-10-0-2 (10.0.2.0/24)を選択します。
  11. [作成] をクリックしてインスタンスを作成します。

インスタンスが起動するまで、しばらくお待ちください。準備が完了すると、[VM インスタンス] ページに緑色のステータス アイコンが表示されます。

gcloud

コンピューティング インスタンスを作成するには、次のオプションを使用して gcloud compute instances create メソッドを実行します。

  • 「オンプレミス」側のネットワーク設定と一致する ZONE: ゾーンとして europe-west1-b
  • http-server タグを指定して HTTP トラフィックを許可する。
  • 作成した SERVICE_ACCOUNT
gcloud compute instances create COMPUTE_NAME \
   --project=PROJECT_ID
   --zone=ZONE
   --image-family=debian-9 \
   --tags=http-server,https-server
   --service-account=SERVICE_ACCOUNT

出力は次のサンプルのようになります。

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/COMPUTE_NAME].
NAME          ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
COMPUTE_NAME  ZONE           n1-standard-1               INTERNAL_IP  EXTERNAL_IP    RUNNING

インスタンスへの接続は、次の手順で行います。

Console

  1. Google Cloud コンソールで、[VM インスタンス] ページに移動します。

    [VM インスタンス] ページに移動

  2. 仮想マシン インスタンスのリストで、作成したインスタンスの行にある [SSH] をクリックします。

gcloud

インスタンスに接続するには、gcloud compute ssh コマンドを実行します。

gcloud compute ssh INSTANCE_NAME \
    --project PROJECT_ID \
    --zone ZONE

Linux インスタンスとのやり取りに使用するターミナル ウィンドウが用意されています。

  1. ターミナル ウィンドウで、Netcat をインストールします。

    sudo apt install netcat
    
  2. hl7v2-mllp-sample.txt ファイルをダウンロードしてインスタンスに保存します。

  3. MLLP アダプターを介して HL7v2 メッセージを HL7v2 ストアに送信するには、ファイルをダウンロードしたディレクトリで次のコマンドを実行します。Service を検査したときに表示された LoadBalancer Ingress の値を使用します。

    echo -n -e "\x0b$(cat hl7v2-mllp-sample.txt)\x1c\x0d" | nc LOAD_BALANCER_INGRESS_IP_ADDRESS 2575
    

    このコマンドを実行すると、MLLP アダプタを介して HL7v2 ストアにメッセージが送信されます。メッセージが HL7v2 ストアに正常に取り込まれた場合、コマンドは次の出力を返します。

    MSA|AA|20150503223000|ILITY|FROM_APP|FROM_FACILITY|20190312162410||ACK|f4c59243-19c2-4373-bea0-39c1b2ba616b|P|2.5
    

    この出力により、HL7v2 ストアが AAApplication Accept)レスポンス タイプで応答し、メッセージが検証され、正常に取り込まれたことがわかります。

  4. Pub/Sub トピックにパブリッシュされたメッセージを表示するには、gcloud pubsub subscriptions pull コマンドを実行します。

    gcloud pubsub subscriptions pull --auto-ack PUBSUB_SUBSCRIPTION
    

    このコマンドは、取り込まれた HL7v2 メッセージに関する次の出力を返します。

    ┌-----------------------------------------------------------------------------------------------------------------|-----------------|---------------┐
    |                                                               DATA                                              |    MESSAGE_ID   |   ATTRIBUTES  |
    ├-----------------------------------------------------------------------------------------------------------------|-----------------|---------------|
    | projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/HL7V2_MESSAGE_ID | 123456789012345 | msgType=ADT   |
    └-----------------------------------------------------------------------------------------------------------------|-----------------|---------------┘
    
  5. また、HL7v2 ストア内のメッセージをリスト表示して、メッセージが追加されたかどうかを確認することもできます。

    curl

    curl -X GET \
         -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
         -H "Content-Type: application/json; charset=utf-8" \
         "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages"
    

    リクエストが成功すると、サーバーはリソースパスでメッセージの ID を返します。

    {
      "hl7V2Messages": [
        {
          "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID"
        }
      ]
    }
    

    PowerShell

    $cred = gcloud auth application-default print-access-token
    $headers = @{ Authorization = "Bearer $cred" }
    
    Invoke-WebRequest `
      -Method Get `
      -Headers $headers `
      -ContentType: "application/json; charset=utf-8" `
      -Uri "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages" | Select-Object -Expand Content
    

    リクエストが成功すると、サーバーはリソースパスでメッセージの ID を返します。

    {
      "hl7V2Messages": [
        {
          "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/MESSAGE_ID"
        }
      ]
    }
    

このセクションを完了すると、MLLP アダプターが GKE に正常にデプロイされ、「オンプレミス」インスタンスから Cloud Healthcare API に HL7v2 メッセージが安全に送信されます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、Google Cloud で作成したリソースをクリーンアップします。

プロジェクトの削除

このチュートリアルで作成したプロジェクトを削除する以下の手順に従います。

  1. Google Cloud コンソールで、[リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

トラブルシューティング

アダプターのエラー

MLLP アダプターを GKE にデプロイすると、アダプターでエラーが発生します。

ローカルでの実行中に発生する Connection refused エラー

MLLP アダプターをローカルでテストすると、エラー Connection refused が発生します。

  • このエラーは、一部の Mac OS ユーザーで発生します。--network=host フラグの代わりに、-p 2575:2575 を使用します。また、--receiver_ip=127.0.0.0 を設定する代わりに --receiver_ip=0.0.0.0 を設定します。コマンドは次のようになります。

    docker run \
      -p 2575:2575 \
      gcr.io/cloud-healthcare-containers/mllp-adapter \
      /usr/mllp_adapter/mllp_adapter \
      --hl7_v2_project_id=PROJECT_ID \
      --hl7_v2_location_id=LOCATION \
      --hl7_v2_dataset_id=DATASET_ID \
      --hl7_v2_store_id=HL7V2_STORE_ID \
      --export_stats=false \
      --receiver_ip=0.0.0.0 \
      --pubsub_project_id=PROJECT_ID \
      --pubsub_subscription=PUBSUB_SUBSCRIPTION \
      --api_addr_prefix=https://healthcare.googleapis.com:443/v1 \
      --logtostderr
    

ローカルでの実行中に発生する could not find default credentials エラー

MLLP アダプターをローカルでテストすると、エラー healthapiclient.NewHL7V2Client: oauth2google.DefaultTokenSource: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information. が発生します。

このエラーは、アダプタで Google Cloud の認証情報が見つからない場合に発生します。このエラーを修正するには、コマンドを再度実行する前に、次のいずれかの方法を試してください。

認証エラー

MLLP アダプタをローカルでテストする際にこのセクションで説明されていない認証エラーが発生した場合は、docker run コマンドを再実行し、以下のように -v ~/.config:/root/.config フラグをコマンドの最後に追加します。

docker run \
-v ~/.config:/root/.config \
...