ETL・大規模基盤開発

電子カルテもレセプトも、データは取り込めた。それでも、分析は始まらない。

「取り込む」ことと「使える状態にする」ことは、別の仕事です。
医療データ基盤の難所は、後者にあります。

なぜ、医療データ基盤は「倉庫」で終わるのか

医療データ基盤の失敗は、技術力の不足で起きるわけではない。一般的なデータ基盤の常識が通じない箇所が、四つある。そこを設計時に見落とすと、データは溜まるが誰も使えない倉庫になる。

仕様は、読めば分かるものではない。
電子カルテ（SS-MIX2、HL7 FHIR）、レセプト（医科・DPC・調剤）、DPC調査データ。いずれも仕様書は公開されているが、格納ルールの解釈、施設ごとの運用差、コード体系の対応関係までは書かれていない。仕様書を読める人と、そのデータを読める人は違う。
仕様は、必ず変わる。
診療報酬改定、コード体系の更新、フォーマットの仕様変更。改定で揺れるのはETLのコードだけではない。標準コードへの対応付け、集計の定義、過去データとの接続——この三つが同時に動く。どこまで遡って作り直すかを決めていない基盤は、改定のたびに止まる。
規模が、設計を変える。
2,400万人規模。小規模データで動いた処理も、件数が桁で変われば「正しいが終わらない処理」になる。分割・並列・再実行の単位は、最初の設計で決めておくしかない。
「取り込めた」は、「使える」ではない。
施設ごとに異なる表記、欠損、重複、標準コードへ寄っていない記録。加工も標準化もマスタ付与もされていないデータは、分析者が毎回同じ前処理を書き直すことになる。基盤の価値は、下流でどれだけ書かずに済むかで決まる。

H&H CONNECTの設計体制

倉庫になるか、解析できる基盤になるかは、判断がどこに置かれているかで決まる。

判断するのは、臨床・システム・データの三領域を一人で横断するコンサルタント。専門と専門のあいだに残る領域を、誰かに渡さずに引き受ける。

そこへ、医療データ基盤の開発を15年以上続け、SS-MIX2・レセプト・DPC調査データから HL7 FHIR まで手がけてきたエンジニアが、処理と運用の設計を持ち込む。

使う側の要求を検証するのは、医療データベース事業者と病院で分析に10年以上従事してきた解析担当。分析用マートの粒度も集計軸も、ここから決まる。

並べているのは職種の幅ではなく、それぞれの深さです。

医療データ基盤には、二つのガイドラインが別々の主体にかかる。厚生労働省「医療情報システムの安全管理に関するガイドライン」は医療機関等に、総務省・経済産業省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」は提供事業者にかかる。

当社は後者に沿って設計し、医療機関等が前者で負う責任を果たせる形に、あらかじめ合意しておく。

準拠は宣言ではない。アクセス制御、権限分離、ログの保全、鍵管理、委託先管理、そして運用体制として具体化されて初めて成立する。

基盤は、主に六つの工程で組み立てる。順序と反復は、目的と環境によって変わる。

取得・取込 — SS-MIX2（標準的ストレージ／拡張ストレージ）、HL7 FHIR、レセプト（医科・DPC・調剤）、DPC調査データ（様式1・EFファイル・Dファイル・Hファイル）。ソースごとに配置・文字コード・更新頻度が異なるため、取込は個別に設計する。
異常検知・補正 — 重複、欠損、不正値、フォーマットの揺れ。仕様外のパターンは黙って弾かず、検知して隔離し、原因を特定してから取り込む。
匿名加工・仮名加工 — 目的（外部提供／自組織内分析）に応じて手法を選ぶ。所見・看護記録など自由記載欄の扱いを含む。
標準化・構造化 — 医薬品・傷病・検査という分析の三種の神器を中心に、ローカルコードから標準コードへ紐付ける。
標準コードに限らず、用量や単位も標準化する。
加えて、所見・看護記録などの自然言語データを必要に応じて構造化する。
分析用マスタ付与 — WHO ATCマスタ、EphMRA ATCマスタ、適応症マスタ、単位換算マスタ、副作用マスタなど、分析に必要なマスタを付与する。
データマート設計 — 粒度と集計軸は、下流で実際に解析する人間の要求から逆算して決める。