This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "TermInfo - On negation (email thread)"

From HL7Wiki
Jump to navigation Jump to search
Line 4: Line 4:
 
*Dear All,
 
*Dear All,
  
:some thoughts on the "negate-in-terminology-or-by-attribute" topic before the meeting tomorrow. I've read through the original
+
: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.
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.
+
: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 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
+
: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.
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
+
: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".
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.
 
: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.
  
 
:PS.
 
:PS.
: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
+
: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?
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?
 
 
:DS.
 
:DS.

Revision as of 12:27, 7 May 2013

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.
PS.
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?
DS.