データ連携システム「連携くん」のアーキテクチャについて解説
1.はじめに
WHITE CROSS株式会社歯科技工DX開発部テックリードの小倉です。
弊社では昨年の2024年12月に連携くんというサービスをローンチしました。
図1. 連携くんロゴ
このサービスでは以下のアーキテクチャを採用しています。
図2. 連携くんアーキテクチャ図
本記事ではこのサービスのアーキテクチャについて解説します。
2.連携くんの開発に至った背景
アーキテクチャの解説を行う前に連携くんの開発に至った背景について解説します。
弊社では技工くんというサービスを運営しています*1。
図3. 技工くんロゴ
このサービスは歯科医院と歯科技工所間で行われるコミュニケーションのDXを実現するためのSaaSアプリケーションです。
サービスを運用している中で歯科医院側のユーザーから歯科医院に訪れる患者情報の管理に用いているレセプトコンピューター（レセコン）に保存されたデータを技工くんに取り込んで欲しいという要望を多数いただきました。
従来、歯科医院へ新規患者が訪れた場合、その患者情報はレセコン上に入力します。
技工くんの導入後は同様の作業を技工くん上でも行う手間が発生していました。
この課題を解消するためにレセコンで登録された患者情報を連携くんへ同期するためのシステムについて検討を開始しました。
これが連携くんの開発に至った背景です。
3.連携くん開発上の制約について解説
連携くん開発上の制約が2つありました。
それはTLSクライアント証明(mTLS)の利用と連携くんの動作環境に関する制約です。
それぞれの制約について解説します。
TLSクライアント証明(mTLS)の利用に関する制約についてご説明します。
mTLSは3省2ガイドラインへ準拠したシステムを構築するために必要になります。
3省2ガイドラインとは厚生労働省と経済産業省と総務省の3つの省庁が発行する2つのガイドライン「医療情報システムの安全管理に関するガイドライン」と「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」の総称です。
医療情報を取り扱うシステムを開発する際にはこの3省2ガイドラインへの準拠が求められます。
技工くんは歯科医療という医療情報を取り扱うシステムであるためこのガイドラインへ準拠した運用を行うよう努めています。
今回実装したいシステムは歯科医院が管理するレセコン上にある患者情報を弊社が管理する技工くんへ転送する必要があります。
これを実現するためには歯科医院のPCと技工くん間で通信を行う必要があります。
この際に3省2ガイドラインの以下の条文を考慮する必要があります*2。
オープンなネットワークにおいて、IPsec による VPN 接続等を利用せず HTTPS を利用する
場合、TLS のプロトコルバージョンを TLS1.3 以上に限定した上で、クライアント証明書を利用
した TLS クライアント認証を実施すること。
上記を踏まえ、歯科医院のPCと技工くん間の通信にはTLSクライアント証明(mTLS)を用いることが決まりました。
以上がTLSクライアント証明(mTLS)の利用が制約に加わった理由になります。
連携くんの動作環境に関する制約についてご説明します。
連携くんは歯科医院のPC上で動作するデスクトップアプリケーションと取得したデータを技工くんに連携するデータ送信システムの主に2つを組み合わせることで動作しています。
このうちのデスクトップアプリケーションについてWindows OS上で動作することが制約に加えられました。
理由は調査の結果、歯科医院に導入されているレセコンのほとんどがWindowsであることが分かったためです。
以上が連携くんの動作環境に関する制約の説明になります。
4.連携くんのアーキテクチャについて解説
連携くんのアーキテクチャは細分化すると以下の3つに大別出来ます。
- デスクトップアプリケーション
- データ登録用API
- mTLSを行うための証明書認証システム
それぞれについて解説します。
4-1. デスクトップアプリケーション
レセコンのデータはクライアントのPC上にあります。
このデータをAPIへ送るためにデスクトップアプリケーションを開発しました。
本章では開発したデスクトップアプリケーションとその開発環境について解説します。
デスクトップアプリケーションにはデータ更新の検知とAPIへのデータ連携の主に２つの役割を任せました。
レセコンは患者情報の新規登録または更新時に指定したディレクトリのCSVへデータを吐き出す機能が搭載されています。
ここで吐き出されるCSVを定期的確認し、もし更新がなければ何もしない、更新があればCSVからデータを抜き出し、データをJSON形式でAPIへ連携させました。
アプリケーションはC#と.NETを用いて開発しました。
理由はアプリケーションの実行環境はWindows OSであることとプロジェクトメンバーのエンジニアがC#が得意であったためです。
実際に開発したデスクトップアプリケーションが図xになります。
図x. デスクトップアプリケーション動作画面
この画面ではレセコンの種類とクライアントPCにインストールした証明書と患者情報が記載されているCSVのディレクトリを設定できます。
これらを設定することで定期的にデータを抜き出し、登録用APIへ送信出来ます。
以上が開発したデスクトップアプリケーションに関する解説になります。
アプリケーションの開発環境はAmazon Workspace Personalを用いて構築しました。
前述した通り、アプリケーションはWindows OS上で動作させる必要があります。
そのためアプリケーションはC#と.NETとVisual Studioを用いて開発することが決まりました。
ただ、弊社のエンジニアが支給されているPCはMacbookです。
Visual StudioのMac OSのサポートは2024年8月で終了しているため別の開発環境を用意する必要がありました*3。
そんな中、以下のアナウンスがAWSから発表されました*4。
本日、Amazon WorkSpaces と WorkSpaces Core は、WorkSpaces Personal での Microsoft Visual Studio 2022 の一般提供を開始します。このリリースにより、WorkSpaces 管理者は Windows 搭載の WorkSpaces を使用する .NET および C++ 開発者に、包括的な統合開発環境 (IDE) を提供できるようになります。
Amazon Workspaces(以下Workspaceとする)とはAWSのクラウド環境上にフルマネージドの仮想デスクトップを構築できるサービスです。
このサービスでVisual Studioが使えるようになればWindows PCを購入せずに開発環境を構築できます。
開発環境に求めるスペックのWindows PCを購入するのに約20万かかります。
Workspaceを使えば約4万円程度に抑えられます（月あたり約1.3万円×アプリケーション開発工数約3ヶ月）。
PCの購入に比べて費用を安く抑えられるためWorkspaceを使う方針に決めました。
以上が開発環境に関する解説になります。
4-2. データ登録用API
データ登録用APIはデスクトップアプリケーションで抽出したデータをアプリケーションのDBに登録するために用意しました。
このAPIについてどのような技術を用いて開発したかを解説します。
データ登録用APIは主にAmazon API Gateway(API Gateway)とAWS Lambda(Lambda)とAWS Serverless Application Model(SAM)とAWS WebApplicationFirewall(WAF)とAmazon RDS Proxy(RDS Proxy)を用いて開発しました。
API GatewayとLambdaはSAMを用いて構築しました。
SAMはInfrastructure as Code (IaC) を使用した、サーバーレスアプリケーション構築のためのオープンソースのフレームワークです*5。これを用いることでAPI GatewayとLambdaを使用したAPIの構築が簡単に設定できます。
sam initを実行するとランタイムに使用するプログラミング言語の選択やLambdaの設定を対話式で設定出来ます。
次にsam buildを実行するとコードのコンパイルや実行可能バイナリの作成、コンテナイメージの構築などデプロイ前に行うべき準備を行ってくれます。
最後にsam deployを実行するとAWS CloudFormationを使用したリソースのプロビジョニングを実行してくれます。
API Gatewayの前にはAWS WebApplicationFirewall(WAF)を設置しました。
設置した理由は医療情報を扱うシステムなのでセキュリティを高める必要があるためです。
WAFではマネージドルールとレートベースルールの２つを設定しました。
マネージドルールはアプリケーションの脆弱性に関する一般的な脅威からアプリケーションを保護する様々なルールをAWSがマネージドに提供してくれる機能です*6。
具体的にはコアルールセットマネージドルールやAmazon IP 評価リストマネージドルールグループといったルールがあります。
コアルールセットマネージドルールは設定するとOWASPTop 10 などのOWASP出版物に記載されている高リスクの脆弱性や一般的に発生する脆弱性など、様々な脆弱性を悪用したリクエストからリソースを保護できます。
Amazon IP 評価リストマネージドルールグループは設定するとAmazonが収集した悪意のあるアクティビティに積極的に関与していることが判明したIP アドレスのリストに記載されたIPからのリクエストからリソースを保護できます。
他にも様々なマネージドルールがあり、これらを設定することでセキュリティが向上します。
レートベースルールはリクエストに含まれる特定の値をカウントし、予め設定したレートを上回るリクエストからリソースを保護する機能です*7。
例えばログインページへのリクエストや特定のヘッダーが欠落しているリクエストを制限することが出来ます。
本システムでは不要なリクエストが大量に届くとコストの増加が懸念されました。
この懸念の対策として1つのIPアドレスから1分間に10回を超えたリクエストが届くとリクエストをブロックするようレートベースルールを設定しました。
RDS Proxyはフルマネージドのデータベースプロキシサービスです*8。
APIを通して受け取ったデータはAmazon RDSで構築したデータベースに登録します。
APIに使用しているLambdaは負荷に応じて自動的にスケールする機能を持っています。
スケールした際にリレーショナルデータベースの同時接続数の上限を上回ってしまうとリクエストを正常に受け入れることが出来なくなってしまいます。
その対策としてRDS Proxyを設置しました。
RDS Proxyはデータベースへのコネクションプールを確立し、データベースへの接続数を最小限に抑えてくれます。
これによりLambdaがDBの同時接続数の上限を上回ってスケールした場合でもDBがリクエストを正常に受け入れる事ができます。
4-3. mTLSを行うための証明書認証システム
mTLSはAWS Private Certificate Authority(AWS Private CA)とAWS Certificate Manager(AWS CM)とAPI GatewayとS3を用いて実現しました*9。
AWS Private CAはマネージドなPrivate CAを構築できるサービスです*10。
このサービスを用いてCAを作成し、CA証明書を発行します。
発行した証明書をトラストストアとして活用するS3に保存します。
API Gatewayにはカスタムドメインを設定します。
この際に保存したバケットのURIをTruststore URIとして設定します。
API Gatewayは作成時にデフォルトドメインが自動的に割り当てられるためカスタムドメインを設定する必要はありません。
しかし、mTLS使用時にはカスタムドメインの設定が必須になります。
ここまで設定するとAPI GatewayにてmTLSが有効化します。
その後、AWS Private CAに紐づけたクライアント証明書をAWS CMにて発行し、クライアントPCに渡します。
これでmTLSを用いた通信が実現出来ます。
5.最後に
歯科医療のDXを推進する中で私達は今回解説した課題に直面しました。
ただ、同様の課題は他ドメインのDXに取り組んでいるエンジニアでも直面する可能性があると思います。
本記事で解説したことがアーキテクチャの設計時に参考になり、DX推進に少しでも貢献出来れば幸いです。
参考
-
WHITE CROSS株式会社, デジタル技工士辞書 技工くんby WHITE CROSS
https://dental.whitecross.co.jp/gikokun -
厚生労働省, 医療情報システムの安全管理に関するガイドライン 第 6.0 版
https://www.mhlw.go.jp/content/10808000/001112044.pdf -
Microsoft Corp, Visual Studio for Mac に関する最新情報
https://learn.microsoft.com/ja-jp/visualstudio/releases/2022/what-happened-to-vs-for-mac -
Amazon Web Services Inc., Amazon WorkSpaces が Microsoft Visual Studio の提供を開始
https://aws.amazon.com/jp/about-aws/whats-new/2024/08/amazon-workspaces-microsoft-visual-studio/ -
Amazon Web Services Inc., AWS Serverless Application Model （AWS SAM) とは
https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/what-is-sam.html -
Amazon Web Services Inc., AWS マネージドルールのルールグループリスト
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-list.html -
Amazon Web Services Inc., AWS WAFでのレートベースのルールステートメントの使用
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-rule-statement-type-rate-based.html -
Amazon Web Services Inc., AWS LambdaでAmazon RDS Proxyを使用する
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-chapter.html -
Amazon Web Services Inc., API Gateway で REST API の相互 TLS 認証を有効にする方法
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/rest-api-mutual-tls.html -
Amazon Web Services Inc., AWS Private Certificate Authority
https://aws.amazon.com/jp/private-ca/
Discussion