実消化やMRアクティビティなどのデータをレポートする、或いは、非定型にデータを取り出し分析する機能について説明します。

マスタ、実消化、MRアクティビティなど、どのデータもBIシステムに連携され活用されます。BIシステムの種類やどうあるべきかの議論もしたいと思います。

実消化データは、実消化システムからBIシ
実消化データをBIシステムで表現するとき
BIツールのデモンストレーションなどで、
データ分析が流行っています。統計解析、予
~ 月次レポートは日次のスナップショット
実消化実績の集計は、自社組織-MRの軸で
JD、NHIから受信した実消化データは、
製薬会社が卸から入手できるのは、あくまで

お気軽にお問い合わせください。

お問い合わせ

実消化データとBI

実消化データは、実消化システムからBIシステムに連携され、そこで他のデータ( 計画、施設ターゲット、マスタ ) などと組み合わされ、本社スタッフや、営業第一線組織に提供されます。

概要を示したのが以下の図です。

上の図で表現しているのは、実消化データにかかわる、BIシステムです。実際のレポートには、市場データや、MRアクティビティデータ、eディテールログデータなどがかかわって来ることもあります。

インプットとしては、実消化データの他に、計画データ、ターゲットデータ、マスタデータがあります。マスタデータは、ディメンションとしても扱われると同時に、特定条件での医師数、施設数などを集計してファクトデータとしても扱われます。

また、ここでは、トランザクションとして、各種データがDWHに取り込まれる絵を描きましたが、この部分は各社で全く異なっているのではないかと思います。

そして、アウトプット。これもまた、各社でまちまちだと思います。上図では、「とある一般的な例」として描きました。

1.基本的なレポート (MR向け、FLM向け、流通担当向け)

これは、Webであったり、Excelのレポートだったり、専用のソフトウェアだったり、媒体は三者三様と思いますが、施設別であったり、MR別、或いは卸別、卸内組織別に、実績、計画、計画進行、前年比などの数値を時系列で並べたベーシックなレポートです。

また、ベーシックな表とは別に、グラフなどビジュアルなレポートもあります。

2.上級マネージャ向けレポート

これは、支店長、営業部長、事業部長といった、上級マネージャ向けのレポートです。表示されている内容は、1.の「基本的なレポート」と変らないのですが、複数のレポートに表示されている情報が、ひとつのレポートに集約され、また、表示順なども、微妙なこだわりを反映したような凝ったレポートです。

このレポートは、案外作るのに手間が掛かりますし、障害発生時も、利用者が少ないにもかかわらず、偉い人が見るため、本社スタッフのIT部門へのプレッシャーは大きいものになります。

3.テーマ型レポート

これは、その時々で作られて、廃れていくレポートや画面たちです。多くの場合、実消化だけではなく、 市場データや、MRアクティビティデータ、eディテールログデータ などもあわせて表現されます。

  • 営業所長(FLM)がMRの状況をひと目で把握できる。
  • MRがDRの状況を多角的に把握できる。
  • 訪問をレコメンドしたりリマインドする。

等々、本部の担当者の思い入れや、トップの考え、時代の流行などによって登場しては消えていきます。

これは実消化のBIというより、CRMで語られるものなので、また別の章で触れていきたいと思います。

4. ヘビーユーザー向けツール

これは、ツール、データ、業務の3つを理解したユーザー、もしくはそのユーザーのアシスタント向けのツールです。①仮説を検証したり、②構築された分析軸に基づくレポートを作成したりといった使い方になります。

機能としては、古い表現ですが、MOLAPとROLAPがあり、上図でもその2つを表現しました。もちろん、会社によって、両方をそなえたところもあるでしょうし、片方だけのところもあるでしょう。

ここでいう、①仮説を検証したり、②構築された分析軸に基づくレポートを作成したり、というのは全く異なる行為です。

①はマーケティングの担当者が、仮説を立て、その仮説の検証や、ブラッシュアップのために試行錯誤してデータに取り組む行為。②はある程度確立された分析軸に基づいてレポートを作成し、アクションや日々の進捗管理に使用するというものです。 BIツールには、このあたりを区別しているものと、微妙にあいまいなものがあります。

4. 手作業による2次加工レポート

そして、割とありがちなのが、『新しいレポートが必要になったが、システムを改修するとコストも時間も掛かるため、ユーザー部門のスタッフが作成する。』とか、『 既存のレポートにはある項目が表示されていなくて、その項目を追加したいがためにスタッフが自作する。』などといったケースです。

これが実は結構かなり曲者です。

パターンとしては、たとえばとある支店や、営業部で、『あるプロモーションをする事になって、その効果測定をしたい。』といった様なケースがあります。IT部門に依頼してもすぐには対応されませんから、部門内のスタッフが自作することになります。

そして、切ないのが、エグゼクティブのスタッフによる、エグゼクティブ向けレポートの作成だったりします。

このアウトプットは、 「2.上級マネージャ向けレポート」にかなり近いのですが、ITのアウトプットをそのままは出せない訳で、作業をされる方の緊張感は大きくなります。朝の早いエグゼクティブの出社時に、前日のレポートを印刷して提出するために、当番でこの作業をやったりする訳です。

2019.9.08

実消化BIシステムのデータ階層

実消化データをBIシステムで表現するときのデータ階層です。

元々は、卸納入先単位のデータが、『卸納入先・自社施設変換マスタ』で引き当てられた製薬会社の施設コードをベースに、その親施設⇒その担当MR⇒所属組織というように上位階層へ集計されていきます。

一見、シンプルなのですが、いくつか注意が必要な事柄を述べます。

領域別MR

外資に多い形態です。領域ごとに事業部が分かれていて、それぞれの事業部が、全国をカバーしています。

つまり、ひとつの施設に対して、複数の事業部ごとにMRがついていることになります。

ここでややこしいのが、領域ごとに事業部を立てている一方で、特定の製品に関しては、複数の事業部が共同でプロモーションを行ったりします。そうなると、その製品に関しては重複して集計していく必要が出てきます。

複数担当制

これは大学病院などで見られます。大学病院には、数百人の医療従事者がいますから、一人のMRでは対応し切れません。そのためひとつの施設に対して複数のMRが設定されています。

これは、実在するMRを主担当副担当として施設に設定するケースや、施設に対しては、架空の担当者コードを割り当てて、施設:MR=1:1を保ちつつ、架空担当者に対して、実在MRを割り当てるなど、さまざまな対応方法があります。

卸軸での集計

一方、 卸納入先単位のデータは、『卸組織・自社コード変換マスタ』を経て、『卸組織マスタ』に沿って、上位階層に集計されていきます。

こちらもいくつか注意が必要です。

MS

MS ( Marketing Specialist )と呼ばれる、卸の営業です。MRは、MSと共同でプロモーション活動を行います。

製薬会社は、卸から納入先マスタを受領して、『卸納入先・自社施設変換マスタ』の整備を行いますが、その際にMSコードも合わせて入手できた卸については、MS別の集計を取ることが出来ます。また、VANから受信する実消化データ内に、MSに相当するレベルのコードが含まれている場合もあります。

MSと共同で活動するMRにとって、MSの実績は有益なものとなります。

ただし、すべての卸から入手できるわけではありません。

卸営業部

卸の組織も、営業所 > 支店 > 営業部 > 企業というような階層となっていますが、製薬会社のシステムはこれらを、「卸または卸営業部」と、「卸組織」といった2つ以上のマスタで管理します。

ひとつは、 支店>営業所といった卸内の組織階層を管理するもの。もうひとつが企業もしくは、営業部程度の大きな組織を単位としてその各種属性管理するものになります。

そして、そこで管理される「卸または卸営業部」というものは、小さな卸の場合は、卸そのもの、4大卸のような大きな卸の場合は、営業部など、おおよそ都道府県の範囲を目安とするような単位で管理されることが多いと思います。

これは、営業事務的な面での要求もあるのでしょうが、卸が合併した場合、ひとつの営業部として取り込まれて、それまでのコードを引き継ぐといったようなことがあるようです。

ちなみに、「営業部」という表現は代表的な表現として用いましたが、その名称は当然卸によって異なります。

大まかに都道府県のサイズと捉えればよいかと思います。スズケンの場合は「営業部」、メディセオの場合は「統括営業部」という事になります。

( ※2019.9現在 各社ウェブサイトにて確認 )

営業部上位組織、企業、企業グループ

営業部上位組織: 大きな卸になると、 複数の営業部をまとめた組織があります。メディセオの場合は、複数の統括営業部をまとめた支社という単位になります。

企業: 4大卸や、複数の都道府県をまたがって営業展開するような比較的大きな卸に対するもので、企業としての卸そのものを示します。

企業グループ: 子会社も含んだグループということになります。たとえば、スズケンの場合、一部のエリアは「スズケン岩手(岩手県)」「スズケン沖縄」などの子会社が担当しています。これは4大卸はどこも同じで一部地域は子会社がカバーしています。

流通担当支店

これは流通を担当する製薬会社の組織になります。通常、MRのいる営業第一線組織とは別に、卸を担当する流通部員が製薬会社にはいます。それらの流通部員の属する組織体系での集計となります。

組織と卸を組み合わせたVIEW

図には示していませんが、製薬会社内の組織、たとえば支店や営業所内の卸別の状況といったような見方もあります。

<4大卸> スズケン、メディセオ、アルフレッサ、東邦薬品

2019.9.10作成、2020.3.17修正

製薬会社にドリルダウンは必要か

BIツールのデモンストレーションなどで、「ドリルダウン」という操作がよく登場します。

たとえば、支店別の実績をみて、関東支店の進捗が悪い。次に関東支店をクリックすると、都県別の進捗が表示され、埼玉県の進捗がよくない。今度は埼玉県を選んで販路別に分解すると、県東部の開業医販路の実績が急に落ち込んでいる・・・。

結構、IT部門やユーザー部門内のIT連携部門にウケがいいのですが、果たして、この様なアプローチで分析することがあるのかと常々思います。

現場で数字を追っている担当者は多くの場合、問題の所在を知っていますし、本社の担当者にもレポートされているのではないかと思うのです。もちろん、支店からのレポートがないというケースもあるでしょうし、そもそも、本社一括管理で支店にマーケティング担当がいないというケースもあるでしょうが、日本の病院と診療所の軒数は合わせて11万件( 医療施設動態調査(平成30年2月末概数))。医師数は32万人。そしてその殆どがマスタ整備されています。(薬局や薬剤師も対象にはなるのでもう少し増えますが・・)

マクロ的な視点からドリルダウンなんかしなくても、一覧で管理出来る数ではないかと思うのです。新たな分解の切り口を試していく場合は別ですが、少なくとも、用意されている分解軸( 支店>営業所>MR、販路大分類>販路詳細、都道府県>市区町村 )を掘り下げていって、問題を発見するというまだるっこしいアプローチはないのではないかと思うのです。

MOLAP、ROLAPという切り分けがありますが、そういう意味で、定型レポートのバックエンドとしてMOLAPというのはありだと思うのですが、非定型用のツールとしては、ROLAPを整備すべきだと思うのですが、みなさまはいかがでしょうか?

( 2019.10.29 )

MRアクティビティと製品納入の関係をデータから解析すること

データ分析が流行っています。統計解析、予測モデル、ビッグデータ、データサイエンティストにデータアナリスト。。。

製薬会社においても同様です。「今期の異動でデータサイエンティストになりました」という方が、『うちのデータを使って何か出来ないですか?』と質問するようなケースもあります。
これは、お気持ちは分かります。世の中では流行っているし、本社のスタッフとしては結果を出さないといけませんから。

「何か出来ない?」はともかくとして、永遠のテーマなのが、MRアクティビティと、製品納入の関係性の分析です。

コール資源は有限ですから、有効活用しなければなりません。

どのような時に、どの顧客に対して、どのようなコールを行えば処方獲得につながるのか、あるいは脱落を防ぐことができるのか。コール先をITがリコメンドできれば、そして、それが有効であれば、経験の浅いMRに対して、あるいはいわゆるスーパーMRでない普通のMRに対して、大変有効なツールとなるでしょう。

データ解析によって作成した予測モデルをSFAに搭載して、訪問先をリコメンドする。なかなか素敵です。

そして、予測モデルを構築するにあたって、過去のMRアクティビティデータと、実消化データを基に解析を行えば、何らかのモデルはアウトプットされます。

コンサル会社さんなどは、「缶ビールの隣におむつを置いたら売り上げが伸びた」的なトークを華麗にされたりするのですが、MRアクティビティと実消化の関連性をデータから予測するのは、データの構造と、網羅性の2つの点から、なかなか難しい面があります

1.実消化実績は病院や薬局で発生するがMR活動の対象は医療従事者である

医師が一人しかいない開業医であれば、MRのコール実績と実消化実績の紐づけは可能です。しかし、大きな病院になると、当然複数の医療従事者がいます。現場にいれば、コールすべき対象医師や採用につながった活動は一目瞭然かもしれませんが、ドボドボッとデータをITに投入したとして「このような状況下でのこのような活動が処方獲得に貢献する」というアウトプット( しかも納得性のある )が、出てくるかというとなかなか難しい。

さらに、大学病院など大きな病院になってくると、ディテールの内容も専門性が高くなってきますので、そもそも、ITでリコメンドするのはなかなか難しい。

2.訪問規制のバイアス

さらに、病院によっては、MRの訪問を規制しているところがあります。その場合、その病院に対するMRの活動量は、病院のポテンシャルに比べて低くなりますので、その結果をもとに予測モデルを作るとミスリードとなります。

3.開業医の場合はどうか

では開業医の場合はどうでしょうか。100軒以上の施設を担当するのは普通ですから、どこを訪問すべきかのリコメンドがあれば有効です。施設に対して実質的に医師1名であれば、有効な解析ができそうです。

しかし、開業医の場合、MRによる訪問活動の他、卸のMSによる訪問活動が影響します。自社MRのアクティビティデータのみを基に予測モデルを作ったとすると、インプットデータに不足ありということになります。

卸によっては、自社MSの訪問データを製薬会社に提供しているところもありますが、すべての卸が提供しているわけではありません。

簡単なようで、なかなか難しいテーマであるといえます。

(2019.11.24)


日次と月次

~ 月次レポートは日次のスナップショットとは限らない ~

実消化レポートにしても、MRアクティビティレポートにしても、BIで提供されるレポートには、一つの切り口に対して、日次で更新されるものと、月次で更新されるものがあります。

これは、製薬会社に限らず、どの会社の営業レポートも同じではないかと思います。たぶん、ご自身の会社の計数管理のレポートなどもそうなっているのではないでしょうか。

この章では、レポートのアウトプットタイミングによる内容の違いについて書いて行きます。

更新タイミングの種類

主な更新タイミングは3つです。

1.日次更新
2.日中更新
3.月次更新

小さな製薬会社であれば、[ 2.日中更新 ] はない場合もあると思います。
また、四半期更新、半期更新、年次更新というものもレポートとしては存在しますが、月次更新の延長と考えていいかと思います。

各更新タイミングの内容

1.日次更新:

毎営業日の夜間(※)に更新され、前日までの当月実消化実績や当月MR稼働実績を集計します。
その日のデータを昨日までの当月データに加算したもので、月末に向かって、「当月実績」が日々増加していくような内容になります。

当月実績、当月計画、当月計画進捗率、当月日別実績、等がレポートの項目になります。

※:土曜の夜間に更新する会社もあります。

2.日中更新(速報):

これは、実消化レポートの更新において行われることがあります。
全ての製薬会社が行っているという訳ではありません。
JDnetやNHIからのデータを日中に複数回取得して、その時点でのデータを公開するというものです。

ベテランの計数担当者であれば、例えば午後3時のデータをみれば、翌朝に公開されるその日の実績が経験的に予測できます。

上図の例では、日中と日次が別のUIになっていますが、昨日までの当月実績に当日速報分をマージして表現するというUIもあります。

また、卸によって、JD/NHIへのアップロード時間は異なっているため、例えば上の例で、12:00公開の日中更新のレポートには、〇〇卸の実績が含まれているが、××卸の実績は含まれていないという事を、ベテランの計数担当者は理解して、当日の着地を予測する訳です。

もう少し、細かくしたのが以下の図になります。

3.月次更新:

一方、月次は、その月が終わったところで、締めた(=確定された)数字を公開します。一ヶ月間の実績を集計して更新されるレポートです。

月別実績、当月実績、当月計画、年/期累計実績、年/期累計計画、年/当期計画、計画進捗、等がレポートの項目となります。

月次のレポートは、一ヶ月間同じものが公開されます。

「その月が終わる」というのは、会社によって違うのかもしれませんが、第3営業日が多いのではないかと思います。

ちなみに、これは、第3営業日までの納入データを計上するという事ではありません。

前月の1日~末日までの伝票データが卸から届くのを、第3営業日までは待つ。という事です。例えば、31日に卸が医療機関に納入したデータは、その日のうちには製薬会社に届かず、翌月(翌日)になって届くという事が起きる訳です。

卸から実消化データが届くのにタイムラグがある訳です。

MRアクティビティデータにしても、「2月の活動報告は3月2日までに日報入力しなさい」といった運用があると思います。

例えば、7月分の実績データは8月の初めにも届きますから、概ね出揃った頃という事で、第3営業日に処理されます。

データ処理日と計上月

ほぼほぼ、第2営業日には前月の伝票データは出そろいますので、第3営業日までに届いた前月データをもって、その月を確定させるという事になります。このあたりは「実消化実績の計上年月」にも書きましたので良ければ参考にしてください。

このように、締め日までは前月の月度で処理を行いますので、日次レポートの月が変わるのは、締め日の後になります。

日次と月次の差異

さて、では第4営業日に、月次レポートが公開されるとして、その内容は日次レポートと同じでしょうか?

おそらく、その答えは製薬会社によって異なります。

日々の日次レポートの締め日の分(最終更新版)のスナップショットを取り出して固定し、月次レポートとしている会社もあるでしょうし、日次は速報的なもので、補正データ、調整データを月次レポートには加味して公開するという会社もあるのではないかと思います。( 下図はスナップショットの場合です。)

月次は日次のスナップショットであるケース

スナップショットのイメージ

『月次 = 日次の最終日のスナップショット』の場合は、当月データの処理としては、出来上がった日次データをコピーしておしまいです。数字は一致します。一見、簡単ですが、トラブル時のリカバリーにリスクがあります。

日次スナップショットの月次処理はトラブル時の復旧が大変

このケースは開発や通常運用はシンプルで楽です。ただし、第4営業日に公開されたレポートに不具合があったことが、第5営業日以降に発見されたりすると、かなり面倒なことになります。日次のデータストアは既に新しい月のデータに置き換わっていますので、バックアップデータを別の環境にリストアして再処理をするなど、手間をかけてのリカバリーになります。

日次は速報、月次は確定情報であるケース

一方、日次は速報版。正式版は月次。というように、公開内容が異なるケースもあります。

例えば、前月施設特定のできなかった変換エラーデータが施設特定されたような場合に当月に計上させる考え方があるという事を以前書きましたが(納入先・施設変換登録月への実績計上)、日次レポートには反映させずに、月次レポートにのみ反映させるといった対応をしているケースもあると思います。

その他にも、一括納入先の按分・相殺データの差し込みを月次にだけ行うといったこともあるかも知れません。そのあたりは各社のシステムによって異なっていると思います。

(2020.02.06 作成、2020.04.02、2020.08.17修正、2021.07.16大幅修正)

自社組織別レポートと卸別レポート

実消化実績の集計は、自社組織-MRの軸で集計する場合と、卸の軸で集計する場合でいくつかの違いがあります。ここで述べることは、すべての製薬会社に当てはまるかどうかはわかりません。こういう考え方があると理解してください。

  1. 仕切価と納入価
  2. 施設でみるか、親施設で見るか
  3. 特定品目の除外
  4. 卸納入先自社施設変換エラーの扱い

1. 仕切価と納入価

自社組織-MRの軸で集計する場合は仕切価を使用するのが一般的です。一方、卸の軸で集計する場合は納入価を使用するという場合があります。製薬会社にしてみれば、卸にはなるべく高く売ってほしいですから、仕切価(製薬会社→卸)ではなく、納入価(卸→施設) を使って評価するというのは理にかなっているように思えますが、最近は、卸の評価の際も仕切価を使用するところが多くなっているのではないでしょうか。また、納入価を非開示にする卸も出てきています。

2. 施設でみるか、親施設で見るか

組織・MR軸で集計する際、施設ではなく、親施設の属性で集計するという考え方があります。親施設でも子施設でも、担当MRは一般的には同じでしょうから、影響はないように見えますが、販路のとらえ方に違いが出てきます。

例えば、大学病院の門前薬局で売れた実績は、大学病院の実績とするというのが、親施設の属性で集計するという考え方です。一方、施設の属性でとらえれば、薬局で上がった実績という事になります。

3. 特定品目の除外

MRは、必ずしも自社製品だけをディーテールしている訳ではありません。他の会社と共同販促、コ・プロモーションを行うことはよくあります。

他社品を共同販促する場合、MRとしては、情報提供活動を行っているため、その他社品の実消化実績も、MRの実績として計上されますが、卸のインセンティブ評価対象からは除外されます。

個別の品目計はAll or Nathingなので分かりやすいのですが、「グロス」や「全国計」といった数字も、自社組織集計レポートと、卸集計レポートでは、構成品目が異なるという事になります。

ただし、この辺りは複雑で、"他社品=卸への評価対象外"が常に成り立つかというとそうではなく、営業的な大人の事情で、"この品目は他社品だけどグロスに含める"というようなことが行われますので注意が必要です。

4. 卸納入先自社施設変換エラーの扱い

JD、NHIから受信した実消化データは、卸納入先自社施設変換マスタを引き当てることによって、製薬会社側の施設を特定します。

したがって、この引き当てが成功しないと、当然、担当MRも取り付けられません。この実績は、「変換エラー」として集計されます。( 個別のMRに割り当てられなくても、全社計としては捉えられます。)

しかし、どの施設なのかはわからなくても、どの卸のどのデポで上がった実績かという事は分かりますので、卸へのインセンティブを計算する際には、集計することが可能になります。

( 2020.03.02作成、2020.08.18修正 )

卸納入先・自社施設変換エラーの集計

JD、NHIから受信した実消化データは、「卸納入先自社施設変換マスタ」を引き当てることによって、製薬会社側の施設を特定します。

この時、一定の割合で変換できないデータが発生します。分かりやすいのは、新規に開業した施設で、まだマスタに登録されていないようなケースでしょう。

この場合、当然どの施設か分からないわけですから、MRに紐づけることもできません。登録が完了するまでは、MRの実績にはなりません。

この実績は、「施設変換エラー」、「未登録」という括りで一つの販路として、扱われますが、全社一括で取りまとめて、支店や営業所の実績にはしない場合と、支店、あるいは営業所の実績に計上するケースがあります。

どの施設か分からないのにどうやって・・・?

と思われるかもしれませんが、受診したデータの施設は不明でも、どの卸のどのデポから上がった実績かという事は分かります。

〇〇薬品の東京北支店
   ↓
北区を担当しているのは、自社の東京支店-東京第1営業所

といったように、卸デポの住所を頼りに特定組織に計上することが可能です。

ただし、この方法では、卸デポごとに「計上先自社組織」を登録駆る必要があり、管理コストがかかりますし、その変換エラー実績が、本当に自組織の担当する施設に対するものかは分かりません。

マスタ管理担当者が、該当する施設を特定して、 「卸納入先自社施設変換マスタ」 を登録することで、当初ある組織に計上されていた実績が、別の組織に移動する。といったようなケースも発生します。

という事で、施設変換エラー・未登録実績を、自社組織のいずれかに計上するのは、コストもかかる上に、ミスリードにもつながります。そのため、営業組織には計上せず、本社等に計上するという考え方もあります。

ただ、変換エラーの発生は営業第一線に非のあることではありませんし、営業第一線の活動の成果として発生した実績ですから、できる限り、営業組織に計上したいという考えも、理解できるものであります。

参考リンク
 卸納入先・施設変換マスタ登録
 納入先・施設変換登録月への実績計上

( 2020.03.05 )

市場データ(実消化)

製薬会社が卸から入手できるのは、あくまでも自社品についてだけです。
このデータでは、競合他社の製品がどれくらい売れているか、自社品のシェアがどれくらいあるのかは分かりません。

そのため、製薬会社は外部の市場データ販売会社からデータを購入します。もっとも有名なのがIQVIAジャパンという会社です。米国に本社のあるクローバる企業で、SFAツールなども扱っています。

この会社は、都道府県別、市区郡別、施設・ブリック別など、様々な粒度のデータを販売し、多くの製薬会社がこのデータを購入しています。

ただし、最小粒度のデータだったとしても、すべての施設が特定されて販売されている訳ではありません。データの提供を行っていない卸があり、特定の地域の精度が落ちるケースなどがありますので注意が必要です。


製薬会社としては、データは細かいほどメリットがあります。しかし、データの粒度が細かくなればその分高額になりますし、購入している製品の種類の数だけ、自社データベースへのインポート処理を構築しないといけません。

製薬会社は製品ごとの必要性に応じて、購入するデータの種類(粒度)を決定します。

粒度の粗いデータを何とか工夫して使うケース

そして、製品によっては、粗いデータであっても施設の特定を試みることができます。

もちろん、プライマリー領域の製品であれば不可能ですが、希少疾病の領域になると、そもそも取り扱う医療機関が限られてきますので、市区郡別のデータだったとしても、ほぼ施設を特定できてしまうという事があります。

そうすれば、データ購入費を削減することができますが、余分な手間がかかることになります。

( 2020.04.02作成、2020.08.18修正 )