ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Finan, Sean" <Sean.Fi...@childrens.harvard.edu>
Subject RE: dictionary-look-fast fails to handle alternative CUIs
Date Wed, 08 Jul 2015 18:46:39 GMT
Hi Britt,

This did come up briefly wrt NCI custom cuis, but there was no urgency so it got shoved onto
a back burner.  I’m glad that you brought it up again as it is something that I’ve been
wanting to enhance.

My thought at the moment is to change CuiCodeUtil (…lookup2.util.) from a non-instantiable
utility class to a singleton.  In the singleton we could keep an array of String prefixes.
 At each conversion of custom cuis String to long, store each unique String prefix in the
array and add [arrayIndex*10000000] to the long version of the cui.  That should allow for
more than enough custom cui prefixes.  Upon conversion back to the String version, grab the
prefix according to the long/10000000 and append accordingly.  Of course, this would work
just fine for single-character prefixes with a 7 digit cui.  Multiple-character prefixes might
require an array of Integer,prefix pairs, where each integer is the number of digits in the
cui:  NLM003 ->  3,”NLM”.

I think that the array of pairs would work – it would just need to be carried through and
tested.  Any thoughts?

Sean

From: britt fitch [mailto:britt.fitch@wiredinformatics.com]
Sent: Wednesday, July 08, 2015 2:23 PM
To: dev@ctakes.apache.org
Subject: dictionary-look-fast fails to handle alternative CUIs

This is largely directed to Sean but open to other feedback as well.

The current fast lookup using a BSV parses the first field as “C” and up to 7 numerals,
padding with “0" as needed to reach that length when applicable [see CuiCodeUtil.getCuiCode(String)]

The CUI string is then substring’d from 1 to len and parsed as a Long.

This is producing issues with other related, but separate, ontologies (MedGen) where the bulk
of concepts use UMLS CUIs but some additional concepts were created by the NCBI where no CUI
previously existed.
These MedGen-specific concepts are created with a prefix “CN” + 6 numerals, resulting
in “N123456” failing to produce a Long.

I wanted Sean’s thoughts on this and to get some feedback on if others are running into
this issue and if the community wants a solution to providing a CUI format beyond the standard
C + 7 numerals.

I’m happy to make these edits and check them in whether that means updating the CuiCodeUtil
class or creating an entirely new BSVConceptFactory if thats what makes the most sense.

Thoughts?









Britt Fitch
Wired Informatics
265 Franklin St Ste 1702
Boston, MA 02110
http://wiredinformatics.com
Britt.Fitch@wiredinformatics.com<mailto:Britt.Fitch@wiredinformatics.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message