矛盾する観測

2009年3月3日

多くのコンピュータシステムは、データを格納し、それを人間にとって有用な情報に変えるために構築されています。これを行うとき、その情報を一貫したものにしたいという自然な欲求があります。結局のところ、物事について二心を持つコンピュータシステムには何の使い道があるでしょうか？

しかし、時にはコンピュータシステムは矛盾するデータを記録し、人間がそれに対処するのを助ける必要があります。この問題は、私が長年前に英国国民保健サービスで医療に携わっていたときに、私の心に最も強く浮かび上がりました。私たちは、医療提供のための概念モデル、つまり電子医療記録のための概念スキーマを構築していました。

振り返ってみると、今なら違うやり方をするだろうという点がたくさんありました。しかし、特に一つ、非常に貴重で重要なことがありました。そのモデルは、私、別のソフトウェア開発者、2人の医師、1人の看護師の間の共同作業でした。臨床医はモデルを理解し、その開発に十分な役割を果たしました。彼らは単なる受動的なレビュー担当者ではありませんでした。その結果、私たちが開発したアイデアは、臨床医が電子医療記録に何を求めているかを考える上で特に価値があったと思います。

臨床医が非常に強く主張していたことの一つは、この矛盾する情報を捉える必要性でした。ロイヤルホープ病院からのメモで私の血液型はAであると書かれており、一方でプレニチュードの姉妹会からのメモで私の血液型はBであると書かれているかもしれません。これは明らかにナンセンスであり、血液型は変化しません。しかし、それらの2つのデータを記録できないわけではありません。さらに調査しない限り、どちらが正しいかはわかりません。再検査して一方を確定したとしても、それがさらなる臨床処置の基礎になっている可能性があるので、間違った方を捨てることはできません。そしてもちろん、矛盾がそれほど明確でないケースもたくさんあります。どちらの矛盾するデータが間違っていたのかを決して見つけられないかもしれませんし、非常にありそうにないが不可能ではない時間経過による変化を発見するかもしれません。

この問題に対処する鍵は、私の血液型をPersonクラスの属性としてではなく、それ自体で独立したクラスとして表現することです。私たちはそれを観測と呼びました。各観測は特定の患者に適用されますが、いつ行われたか、誰が行ったか、どのように行われたかなどの情報も記録します。

また、観測は、存在するものについてだけでなく、存在しないものについても行うことができることがわかりました。したがって、状況によっては、私の血液型を特定できないかもしれませんが、血液型Oではないと言うことは可能です。これは血液型Oがないという観測として表現できます。（この例が可能または妥当かどうかはわかりませんが、現実的な例をすぐに思いつくのは難しい場合があります。）多くの場合、診断プロセスでは、存在しないものを観察することが非常に重要です。

観測を使用すると、患者に関する情報を決定する方法が変わります。単に患者の血液型を尋ねるのではなく、患者のすべての血液型観測を確認します。すべてが同じであれば、その値を使用します。それらが異なる場合は、さらに詳しく調べる必要があります。多くの場合、観測は時間とともに適切に変化するため、時間経過に伴う私の体重の変化をプロットするために、時間経過に伴う私の体重のすべての観測を確認することがあります。

矛盾する観測を保持する必要がある一方で、それらの1つが間違っていると考えた場合は、それを捉える必要もあります。骨折などの観測は時間とともに真実ではなくなりますが、上記の血液型の例はエラーである可能性が高くなります。エラーの場合は、ある観測を別の観測で却下（または反論）するという概念があります。たとえば、私が血液型Aであると判明したアルビオン病院での別の検査があるとします。この観測は、プレニチュードの姉妹会の観測を却下することになります。観測を却下することは、それが決して真実ではなかったと信じていることを示します。古い観測を削除するのではなく、却下されたとマークし、アルビオン病院の観測にリンクします。

情報の重要な特性は、行動を導くために使用されることです。却下された観測は、さらなる観測の証拠として、または介入を正当化するために使用された可能性があります。観測が却下されたら、それらのリンクをたどって結果を調査できるため、これらのリンクを記録に保持することは不可欠です。私たちが却下したばかりの観測が別の観測の証拠の重要な部分である場合、それも疑問視して却下する必要があるかもしれません。このように、観測は、患者についてさらに学ぶにつれて調べることができる証拠の網を形成します。

もちろん、ほとんどの場合、このような複雑なスキームは使用しません。私たちはほとんどの場合、一貫性があると想定される世界でプログラムを作成します。しかし、その快適な想定から離れなければならない時があります。そのような場合、明示的な観測は便利なツールになります。

(これについてさらに興味がある場合は、「分析パターン」の第3章を参照してください。今やり直せばもっとうまく書けるだろうと確信していますが、コアコンセプトは今でも非常によく維持されているようです。また、この作業に携わってくれた同僚（Tom Cairns、Anne Casey、Mark Thursz、Hazim Timimi）にも感謝します。)