You are correct, the sentences break on colon and the negation uses the sentence as a lookup window.
There are a few things you might be able to do: 1.) You could write an annotator to post process the sentences, merging those that end in a colon, or maybe a colon followed by yes/no/etc... 2.) You could write an annotator to create a new annotation that encompasses 2 sentences where the first one ends in a colon, and then update the negation to use that new annotation as the lookup window instead of the default Sentence. 3.) You could change the type of the lookup window to something larger in scope that already exists like a Segment, but this I think that is likely to produce more bad negation than good. Other might have different suggestions. Hope that helps, Britt Britt Fitch Wired Informatics 265 Franklin St Ste 1702 Boston, MA 02110 http://wiredinformatics.com [email protected] > On Dec 6, 2016, at 12:25 PM, Mullane, Sean *HS > <[email protected]> wrote: > > Hello all, > > I have noticed a common theme in our notes where a list of conditions are > listed with yes/no indicators, like this: > > Hyperlipidemia: Yes > Hypercholesterolemia: Yes > Chronic Renal Insufficiency: N/A > Chronic Renal Failure on Dialysis: No > Acute Renal Failure: Yes > Family History of CAD: No > > This is an area where good negation detection is important but I haven’t very > good results. The sentence segmentator sees this as 12 separate sentences, > but I would think proper behavior would be to consider this as 6 sentences > (breaking sentences on line break but not on colons). I suspect this is why > the negation detection is not working well here, but I’m not well-versed in > how the negation annotator works. Can anyone recommend a way to get better > results here? > > I have tried a few variants of the AggregatePlaintextFastUMLSProcessor and > AggregatePlaintextUMLSProcessor with no improvements. > > Thanks, > Sean
signature.asc
Description: Message signed with OpenPGP using GPGMail
