本研究所では、日本と海外のIT技術およびその利用方法を比較し、両者の間にある格差について考えていく。日本では、コンサルティングなど“知恵”が生み出す成果物に対し、お金を払う感覚が欠けている。一般には、それが「目に見えないから」という理由で説明される。今回は、知恵を可視化するテクノロジについて、第1回や第4回で紹介した米国のdbMotionを例に、データ設計の観点から触れていこう。
最近も疑問に思うことがあった。日本では、システムを発注するときにどんなものが必要なのかお客様の要件が決まっていないことが多い。最近では、RFP（提案依頼書）というものを大手システム会社がうるさく言うようになったおかげで、ユーザー企業もRFPを意識するようになってきている。
脳に汗をかく仕事に対価を払えるか
ところが、「これが今回のRFPです」と顧客企業から渡された資料を見ると、まず要件が固まったものではない。仕様を決めるのが無理であるならば、作業もしくはデータのフローを「ポンチ絵でもいいから出してほしい」と思うことが多々ある。ポンチ絵であっても、そこから、データの設計をしていけるからだ。
日本では、業務もしくはサービスの分析に時間とお金をじっくりかける感覚がないように思う。その企業のどこが問題で何を解決すれば効率が上がるかを考える“知恵”にお金を払う感覚はない。たまに「それは提案型営業のことですか？」と言われることもあるが、パターン化した提案型営業とはまったく別物である。
最大の違いは、一企業のためにどれだけの知恵を出せるかだ。しかし、ここが問題で、脳に汗をかく仕事は特に見えないのでお金を払いづらい。それに、いったん“知恵”を聞いてしまうと払うのが惜しくなる。
今回は、知恵を可視化する技術を、第1回と第4回で紹介したdbMotionを例に、データの設計の観点から少し触れてみたい。彼らは、医療の世界において、一つの知恵を可視化し、その価値をユーザーに体感させることで成長できたと考えられる。ユーザーが使う画面にデータが表示されるまでの内部プロセスを可視化すると同時に、目に見えないノウハウで差別化を図ることで、世界のデファクトスタンダード（事実上の標準）を手に入れたのだ。
それでは、dbMotionの内部で何が行なわれているのか探ってみたい。そのためにまず、dbMotionのアーキテクチャを見てみよう。
データ設計のための三つのレイヤー
dbMotionにおいては、「The Data Integration Layer」と「The Data Layer」と「The Communication Layer」の三つのレイヤーがデータ設計を行う上で大きなポイントになるだろう（図１）。dbMotionのWebサイトに、これら三つについて英語の説明がある。試しにGoogleの翻訳機能を使って翻訳してみた。
The Data Integration Layer
「データ統合レイヤーは、臨床データの統合レイヤーからのデータ収集を担当しています/運用システムに関係なく、ソースやフォーマット。 このレイヤーに変換する機能dbMotion UMSにマップすると、このデータは、個別の患者に特定のデータ要素間の論理的な関係を確立する。 レイヤーは、データの統合システムから医療情報を集約し、異種の臨床用語、語彙があるデータ構造のマッピングツールや他のロジックを使用してコンテンツを統合、オーケストレーション、調和のデータ」（Googleによる翻訳結果まま。以下同様）」
The Data Layer
「データ層は、 dbMotion臨床データリポジトリ（のCDR ）は、患者情報を管理し、データ統合レイヤーによって取得を格納する永続的なデータベースホストしている。 CDRは、組織の物理的なドメイン内に、データの所有権を、セキュリティとプライバシーの制御は、組織で定義されて存在します。 データ層はまた、すべてのデータの検索要求のdbMotion UMSに基づいて、元のデータ形式に関係なく、場所、またはコレクションプロセスの単一のインタフェースを提供します」
The Communication Layer
「通信レイヤーの様々なローカルdbMotionリポジトリおよび/または他のリモートデータプロバイダ薬局（など）から、臨床データの収集を担当しています。 要求に応じて、その関連性の高いデータとフォームを仮想患者オブジェクト（ VPO ）のビルディングブロック-患者の中心的なデータを含む統合的な患者情報を動員して、使用されるオブジェクトを収集します。 分散型/連携dbMotion実装では、通信レイヤーのデータモデルの地図と、各ローカルのリポジトリのデータ同期、およびネットワーク情報の流れを管理します」
