Difference between revisions of "TermInfo - On negation (email thread)"
(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...") |
|||
Line 4: | Line 4: | ||
*Dear All, | *Dear All, | ||
− | :some thoughts on the "negate-in-terminology-or-by-attribute" topic | + | :some thoughts on the "negate-in-terminology-or-by-attribute" topic before the meeting tomorrow. I've read through the original |
− | 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 |
− | specification, the email thread and the document posted on the wiki. I | + | 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. |
− | 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 | + | :To start somewhere, logical negation, as exists in some formal languages such as description logics and relational algebra, is really clear. |
− | 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 |
− | Negation in this context means complement, e.g. "not diabetes" means | + | query. However, this logical negation, as pointed out, is not available in the SNOMED CT dialect of DL (unless Peter can convince IHTSDO to |
− | "everything but diabetes" in both an OWL class definition and in a SQL | + | change), nor is Act.negationInd a kind of logical negation. negationInd is a normal attribute and it's semantics is up for interpretation. |
− | 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 | + | :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 |
− | 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 |
− | DL reasoning (e.g. in OWL) the unique name assumption is *not* made, | + | 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 |
− | i.e. if two entities have different names it does not entail that the | + | have to explicitly state that two classes are disjoint. Additionally, DLs typically make the open-world assumption while database systems |
− | two classes are not equivalent. There might be two names for the same | + | 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 |
− | (type of) thing. In most DLs (including OWL and SNOMED CT) one would | + | 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 |
− | have to explicitly state that two classes are disjoint. Additionally, | + | know something, then no assumption is made about truth or falsehood. Note that reasoning with EHRs would in most cases be more like |
− | DLs typically make the open-world assumption while database systems | + | "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. |
− | 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 | + | :This leads to next (and main) issue: what are the clinical requirements for recording negated statements in a standardized, structured manner? I |
− | 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 |
− | have begun to suspect that the clinical requirements have little to do | + | very complex and next-to-uninterpretable statements, there might not be a need for (or at least cost-benefit ratio supporting) standardization |
− | with logical notation. While natural language allows the formulation of | + | of such representations. When limiting negated statements to those which occur commonly and have large impact on patient safety, only two cases |
− | very complex and next-to-uninterpretable statements, there might not be | + | comes to my mind: the exclusion of diagnosis (or condition...), including exclusion of e.g. allergies, and stating that some (important) |
− | a need for (or at least cost-benefit ratio supporting) standardization | + | 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 |
− | of such representations. When limiting negated statements to those which | + | 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 |
− | occur commonly and have large impact on patient safety, only two cases | + | statement would relate to structured care plans. Also note that it would make sense to state that "patient is not allergic to penicillin" but |
− | comes to my mind: the exclusion of diagnosis (or condition...), | + | that it would be hard to find a use case for statements on the form "patient is allergic something but not to penicillin". |
− | 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 | + | :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. |
− | 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 | + | :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 |
− | 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 |
− | 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? | to do X" or "planned not to do X". Is this the case? | ||
:DS. | :DS. |
Revision as of 12:25, 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.