Mailing-List: contact notifications-help@ctakes.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ctakes.apache.org
Date: Thu, 9 Jul 2015 19:24:05 +0000 (UTC)
From: "britt fitch (JIRA)" <jira@apache.org>
To: notifications@ctakes.apache.org
Message-ID: <JIRA.12843941.1436469813000.146650.1436469845100@Atlassian.JIRA>
In-Reply-To: <JIRA.12843941.1436469813000@Atlassian.JIRA>
References: <JIRA.12843941.1436469813000@Atlassian.JIRA>
 <JIRA.12843941.1436469813124@arcas>
Subject: [jira] [Created] (CTAKES-368) Allow alternate CUI formats in fast
 dictionary lookup module
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

britt fitch created CTAKES-368:
----------------------------------

             Summary: Allow alternate CUI formats in fast dictionary lookup=
 module
                 Key: CTAKES-368
                 URL: https://issues.apache.org/jira/browse/CTAKES-368
             Project: cTAKES
          Issue Type: Improvement
          Components: ctakes-dictionary-lookup
    Affects Versions: 3.2.2
            Reporter: britt fitch
            Assignee: Sean Finan
             Fix For: 3.2.3


The current fast lookup using a BSV parses the first field as =E2=80=9CC=E2=
=80=9D and up to 7 numerals, padding with =E2=80=9C0" as needed to reach th=
at length when applicable [see CuiCodeUtil.getCuiCode(String)]

The CUI string is then substring=E2=80=99d from 1 to len and parsed as a Lo=
ng.

This is producing issues with other related, but separate, ontologies (MedG=
en) where the bulk of concepts use UMLS CUIs but some additional concepts w=
ere created by the NCBI where no CUI previously existed.
These MedGen-specific concepts are created with a prefix =E2=80=9CCN=E2=80=
=9D + 6 numerals, resulting in =E2=80=9CN123456=E2=80=9D failing to produce=
 a Long.

It is preferred to allow alternative CUI formats.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)