This wiki has undergone a migration to Confluence found Here

TermInfo - On negation (email thread)

From HL7Wiki
Revision as of 12:23, 7 May 2013 by Rhausam (talk | contribs) (Created page with "====6 May 2013==== Daniel Karlsson *Dear All, :some thoughts on the "negate-in-terminology-or-by-attribute" topic before the meeting tomorrow. I've read through the original sp...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

6 May 2013

Daniel Karlsson

  • Dear All,
some thoughts on the "negate-in-terminology-or-by-attribute" topic

before the meeting tomorrow. I've read through the original specification, the email thread and the document posted on the wiki. I don't claim to fully understand everything said, specifically I'm definitely a non-expert in HL7 modeling, but, at least, it seems that there is no single "negation problem" but a range of issues, some primarily related to negation and some not.

To start somewhere, logical negation, as exists in some formal languages

such as description logics and relational algebra, is really clear. Negation in this context means complement, e.g. "not diabetes" means "everything but diabetes" in both an OWL class definition and in a SQL query. However, this logical negation, as pointed out, is not available in the SNOMED CT dialect of DL (unless Peter can convince IHTSDO to change), nor is Act.negationInd a kind of logical negation. negationInd is a normal attribute and it's semantics is up for interpretation.

Negation in DL is also different from negation in e.g. SQL (e.g. using

the NOT operatior in a WHERE clause) in at least two ways. Typically, in DL reasoning (e.g. in OWL) the unique name assumption is *not* made, i.e. if two entities have different names it does not entail that the two classes are not equivalent. There might be two names for the same (type of) thing. In most DLs (including OWL and SNOMED CT) one would have to explicitly state that two classes are disjoint. Additionally, DLs typically make the open-world assumption while database systems typically make the closed-world assumption. Closed-world assumption is the assumption that if you don't know something to be true, then it's false, i.e. that the system holds complete knowledge of the world or situation. Open-world assumption is the opposite, i.e. that if you don't know something, then no assumption is made about truth or falsehood. Note that reasoning with EHRs would in most cases be more like "open-world" than "closed-world". E.g. even if there is no record of pc allergy, it's safe practice to assume that the record is not complete and ask the patient.

This leads to next (and main) issue: what are the clinical requirements

for recording negated statements in a standardized, structured manner? I have begun to suspect that the clinical requirements have little to do with logical notation. While natural language allows the formulation of very complex and next-to-uninterpretable statements, there might not be a need for (or at least cost-benefit ratio supporting) standardization of such representations. When limiting negated statements to those which occur commonly and have large impact on patient safety, only two cases comes to my mind: the exclusion of diagnosis (or condition...), including exclusion of e.g. allergies, and stating that some (important) procedure was not done (and thus has to be made at a later stage). The first is probably the most important and the second is probably the more complex. As a statement of the second kind would only make sense if the procedure which was not done was planned or at least expected, such a statement would relate to structured care plans. Also note that it would make sense to state that "patient is not allergic to penicillin" but that it would be hard to find a use case for statements on the form "patient is allergic something but not to penicillin".

Anyhow, if Terminfo could focus on those two use cases, progress could

most probably be made faster and the chances of impact would probably also be improved.

In addition, when modeling using the RIM one problem seems to be that

there is no priority order between attributes, e.g. whether the moodCode have priority over the negationInd attribute. It seems to be impossible to determine if negationInd = true, moodCode = plan means "not planned to do X" or "planned not to do X". Is this the case?