E2B(R3)のnullFlavorはどう選ぶ？不明と未収集の確認手順

症例の情報が揃わず、E2B(R3)の項目に値を入力できない場合、まず何が分からないのか、なぜ値を提供できないのかを確認します。不明、尋ねたが得られなかった、まだ尋ねていない、知っているが伏せる、という状態は異なります。その状態を整理した上で、対象項目が許容するnullFlavorを選ぶことが基本です。

nullFlavorは、値を提供できない理由を表す

ICH E2B(R3)実装ガイドのデータ型とnull flavorの説明は、内容を持たない項目について、その理由をコードで表す仕組みを示しています。すべての空欄を同じ値で置き換えるものではありません。任意項目を送信しない扱い、項目を含めてnullFlavorで表す扱い、実際の値を入力する扱いは、項目ごとの定義や条件を確認して選びます。

本稿では、日本語実装ガイドに示された定義と、国内のE2B(R3)二課長通知の改正後全文を併せて参照します。国際ガイドにあるコードの一覧だけで、国内のすべての項目に利用できるとは判断できません。日本の報告分類や項目の補足に、利用できる値や追加の制約が示されているためです。

不明と未収集を分け、許容されるコードを確認する

実装ガイドは、値が不明な場合、情報入手を試みた場合、まだ試みていない場合を区別しています。例えば原資料が空欄であるだけでは、報告者が知らなかったのか、質問されていないのかまでは分かりません。照会や受付の履歴を確認し、理由を把握できる範囲で整理します。次の表は意味の比較であり、各コードが使える項目の一覧ではありません。

NAは、適切な値が存在するが現在分からない状態とは異なります。MSKも、個人情報に関する項目だから自動的に選ぶものではなく、情報を知っているが提供しない状況かを確認します。項目で許容されるコードが限られる場合もあるため、理由に最も近そうな略語を見つけただけで入力を確定しないようにします。

対象項目の許容値と国内の補足を照合する

国内のE2B(R3)実装ガイドに対応した市販後副作用等報告及び治験副作用等報告についてには、項目ごとの入力条件、許容値、NullFlavorと補足が示されています。同じ意味の情報欠如でも、項目や報告の条件によって入力方法が異なることがあります。まず対象項目を特定し、該当する報告分類の条件を確認します。

1. 対象となるE2B項目番号と、親項目や繰り返しの単位を確認する。
2. 実装ガイドで、その項目の定義と許容される値を読む。
3. 国内通知の同じ項目で、NullFlavor欄と補足を照合する。
4. 実際に分かっている内容と、値を提供できない理由を対応させる。
5. 適用に迷う場合は、伝送担当者とPV責任者等へ根拠とともに確認する。

例えば国内通知のD.7.2の自由記載には、MSKの利用について外国症例に関する制約が示されています。ある項目でMSKが選べた経験を、別の項目や国内症例へそのまま広げることはできません。項目番号に加え、今回の症例や報告分類に対応する条件まで見ることが、実装ガイドの一般定義と国内の入力ルールをつなぐ手順になります。

患者名が分からない場合と、伏せる場合を区別する

国内E2B(R3) Q&AのQ62は、D.1の患者の名前又はイニシャルが不明・未記載の場合はNull Flavorで記載するとしています。また、患者略名を知っているが個人情報保護のために記載しない場合には、MSKを用いると明示しています。知らない場合と、知っていて伏せる場合を分けて扱う具体例です。

架空のイニシャルを作って、入力欄を埋める扱いにはしません。原資料に患者名がない場合は、まず不明なのか、情報が伏せられているのかを確認し、D.1の許容値とQ62の取扱いに沿って記載します。担当者が単に閲覧できないという事情と、送信者が情報を保有しているかという事情も、必要に応じて分けて確認します。

照会済みで回答を待っている状態など、作業途中の情報もあります。その場合は、現在確認できる状態を記録し、情報が得られた後の見直しにつなげます。nullFlavorを入力したことだけをもって、追加収集の必要性や医学評価の論点が解消したと扱わず、何が未確認かを症例の担当者が把握できるようにします。

伝送前は、コードの妥当性と情報の意味を両方点検する

伝送用データが形式上の検証を通ることと、症例の情報状態を正しく表していることは、それぞれ確認が必要です。許容コードが入っていても、実際には入手済みの値がある場合や、他の欄に相反する説明がある場合には、原資料と作業履歴へ戻ります。文字列としてコード名を入力しただけで、所定の伝送表現になっているかも確認します。

• 実際の値が得られている項目を、情報欠如として送ろうとしていないか。
• 選んだ理由と、原資料・照会履歴の内容が一致しているか。
• 対象項目と報告分類で、そのnullFlavorが許容されているか。
• 症例経過や他の項目と、情報の有無に矛盾がないか。
• 続報で情報が判明した際に、更新すべき項目を把握できるか。

例えば照会票の欄が空いている場合、まだその項目を尋ねていないのか、尋ねたが回答が得られなかったのかを照会担当者に確認します。理由が分からなければ、原資料の空欄から収集状況を推定して記録するのではなく、理由が未確認であることを作業記録へ残します。コードの定義と実際の事実が対応することを優先します。

同じ患者に関する情報でも、名前は伏せられていて、別の属性はまだ収集していないという場合があります。その場合、患者情報全体へ一つの理由をまとめて適用するより、対象項目ごとに情報の状態を見ます。原資料と入力欄の対応が細かく分かれているほど、取得済みの値まで一括して情報欠如に置き換えることを避けやすくなります。

見直し時には、画面に表示される不明というラベルと、実際の伝送用コードの対応も確認します。画面上の一つの表示が、複数の情報状態をまとめている可能性があるためです。原資料から最終的な出力まで同じ意味が保たれているかを、伝送担当者とともに確認します。

実務では、項目名、値を入力できない理由、照会状況、参照した定義を一緒に確認できると、修正の根拠が伝わります。一律の空欄補完をする前に、今回の症例で何が分かっているかを確かめ、国内ルールに照合します。どの表現が適切か判断が分かれる場合は、社内のPV責任者や薬事・伝送担当者に確認します。