As can be seen by the code below, this routine was first written for release 1.16 while we are currently on 3.12.

I find no place where the partial key retrieval functionality (searcharg])is documented. It seems to work - most, but not all, of the time.

When retrieving from a file with keys that include 354.9 and 354.90 and given a search argument of 354.9] one would expect to retrieve both of those keys. It retrieved only the 354.9 key. In other similar instances, however, it does work properly. The definition of 'CODE' specifies left justification.

Does anyone have a suggestion to make it work all of the time, or should I just scrap it and do the task another way?

Thanks,

Lewis Unger

(and, sorry for the prior empty posting - premature enter keyed)

————– Code example:

SUBROUTINE ICD.SPECIFICITY.CHECK(CODE.PARAM,STATUS.PARAM)

* Title……..: ICD.SELECTION * Author…….: * Date………: 04/10/00 * AREV Release.: 1.16 * Description..: To verify correct level of specificity being imputted * for ICD codes.

DECLARE SUBROUTINE BTREE.EXTRACT

ESC=CHAR(27)

OPEN 'ICD.CODES' TO ICD.IMPORT ELSE PRINT "CANNOT

OPEN ICD.CODES FILE"; STOP

OPEN 'DICT ICD.CODES' TO DICT.ICD ELSE PRINT "CANNOT OPEN DIAGNOSIS FILE"; STOP

STATUS.PARAM=0

CODE =CODE.PARAM

CODES2 ='

SEARCH2=CODE':@VM:CODE:]':@FM

* look at the code that was entered on the screen

* are there any codes with more detail?

BTREE.EXTRACT(SEARCH2, "ICD.CODES",DICT.ICD,CODES2,'S',FLAG)

NUM=COUNT(CODES2,@VM) + (CODES2 NE '')

IF NUM ] 1 THEN

• if more detail is needed then the code is no good.

STATUS.PARAM=0

END ELSE

STATUS.PARAM=1

END

RETURN

---

In the definition of the CODE field, ensure the length is longer than the longest data in the table.

Lewis,

The appearance of numerics with decimals in external form the key structure is perhaps not the best way to handle such data. In most cases we'd opt to store the decimal as an integer and then process it for display with an ICONV/OCONV (as is conventional in AREV).

Further, we'd enquire as to the justification and the length of this numeric field. The ] notation is a standard pseudonym - refer to "containing" or "beginning" or "ending" and the or ] or substitutions. If you index a field truncated for display purposes then the indexes can sometimes be awry.

The Sprezzatura Group

World Leaders in all things RevSoft

In your example, I think the problem is that both evaluate to the same thing when interpreted as a number. The question is not, then, whether a partial key search works but how to make numbers be indexed as strings. One way to do this would be to add a single non-numeric digit.

Thank you very much for your response.

Just to clarify things:

These codes are not always numeric, though the example chosen was. (They are disease diagnosis codes and can contain alpha characters.) They need to be viewed as pure character strings and searched on a substring of the whole. The definition of 'CODE' specifies an 'L' justification, a 'varchar' type and a length well larger than the longest possible code.

L.U.

Thank you very much for your response, Johathan.

Just to clarify things:

These codes are not always numeric, though the example chosen was. (They are disease diagnosis codes and can contain alpha characters.) They need to be viewed as pure character strings and searched on a substring of the whole. The definition of 'CODE' specifies an 'L' justification, a 'varchar' type and a length well larger than the longest possible code.

L.U.

Thanks, Victor for your response.

I would expect (hope) that the definition of the indexed field would control how it gets indexed. Just to clarify things:

These codes are, in fact, not always numeric - though the example chosen was. (They are disease diagnosis codes and can contain alpha characters.) They need to be viewed as pure character strings and searched on a substring of the whole. The definition of 'CODE' specifies an 'L' justification, a 'varchar' type and a length well larger than the longest possible code.

L.U.

Lewis,

I know this is not a fix. And well I would try it to see if this works. At least then you are going in the correct direction to discover your problem.

Create a symbolic so that it always prefixes your code with an "A". Then index the symbolic. Then test the symbolic with your same program code (except for the prefixing "A"). If the index works correctly, then you have an idea on what the problem is. If it continues to work the same old way, then I would consider a bug in the indexing process.

Next, I would try a symbolic that would remove all characters that are not alpha numeric (A-Z, and 0-9). Also modify your index lookup accordingly. See if that would solve the problem. Unless you have an issue of the code being equal to "399.1" and "3991". Because then the alpha numeric would not work. Or maybe it still would???

Those are the kind of tests I would try, so as to find some clue to what is causing the problem.

Lewis ..

I also use the ICD-9 table in one of my applications and indeed also have to deal with the ICD code in both a "flat" format and also as a decimal format. This is compounded by the Alpha leading character. Essentially, I do the following:

1. I import the table from HCFA in a tab-delimited variable length ASCII format into a variable called REC. Then CONVERT TAB to @FM. The Key is REC, the description is REC. Then I make a symbolic which looks like a cross-ref by parsing the pieces. So, for example a key of V12312 will parse into V (the prefix) 12 (the integer portion of a decimal format, 312 the fractional part and V12312 and V123.12. Then I b-tree these elements. I also have a cross-reference on the description as well. Since the user is not permitted to add "new" records to this table, although thay may delete, but inevitably they will get replaced on an update, I don't worry too much. Partial searches are pretty easy this way.

HTH

Don Miller

C3 Inc.

] I would expect (hope) that the definition of the indexed field would control how it gets indexed.

Unfortunately, I think you will have to change your expectation. Arev is essentially not typed. The type you specified in the dictionary has no effect on the index.

The untyped nature of Arev can cause problems, but as long as you are aware of it and can anticipate situations where it might occur, you can code around it. Also be aware of scientific notation. For example, '4E3' will probably be indexed the same as '4000'.

You may be able to alter the index code to handle this situation, but that would involve writing custom code to build the index. That'r probably more trouble than it's worth.

You may be able to solve the problem completely by creating a symbolic field that appends a character to the end of the value. If you use just partial searches, this last character is irrelevant. You could probably even use a space so that you can print the symbolic field.

Then use the index for this symbolic field in your application.

View this thread on the forum...