Re: [Gnumed-devel] Coding SOAP - Richard's comments

[Karsten Hilbert]

On Fri, Jul 09, 2004 at 05:48:36PM +1000, Richard wrote:
> To reply to this earlier thread, I've worked extensively with coding in 
> 3 IT projects - script writing, pathology and diabetes. We explored many 
> of the coding systems and certainly ICPC Plus came out ahead in terms of 
> using more natural language (especially GP oriented) and can be mapped 
> back to the others.
In GnuMed you can attach any number of codes from any number
of coding systems to a single soap row.

> Now if you follow the data entry paradigm I've outlined extensively (and 
> well exemplified in the docs on say pathology ordering, data in the SOAP 
> edit area, like all the edit area is easy to enter and easy to code if 
> part of the entry system involves text delimiters ie.
Why of course. But that's entirely an implementation detail.

However, it leads to a very interesting question: How does one
handle 1-to-many associations from soap row to code ?

Please consider the following example:
    O: red drum, swelling behind ear, pain on pressure
Coding system A will have the codes c1, c2, and c3,
respectively. How does one store that ?

1) Store "red drum, swelling behind ear, pain on pressure" as
   one row in clin_narrative. Link 3 rows in the code table to
   that row. This does not allow to differentiate which finding
   corresponds to which code. However, this may not be
   necessary as it is the same as if we stored a Chinese
   version of the narrative in addition to English. Same
   content (within the limits of coding system A).

2) Store a markup version of the narrative where coded items
   are, say, numbered and the code rows reference both the row
   primary key and the index number within that row. Ugly.

3) Allow only one code type per row, forcing the above narrative
   to be split across 3 rows. Problem is that the meaning of
   codes from different coding systems may overlap the "coded
   range" within the narrative, hence how to split it ?

Why does it seem useful to be able to know the exact
correspondence of phrase to code and not just set of phrases
to set of codes ? It would allow for the needed precision when
suggesting codes for phrases from earlier usage, eg. we
wouldn't want to suggest all codes for a set of phrases if the
new set of phrases is different from the previous. If the user
types "red drum, swelling behind ear" but not "pain on
pressure" we'd want to leave out the code c3 for the missing
part. However, as we deal with rather tiny text fragments it'd
probably not matter too much to offer a few unneeded codes as
long as their narrative (from the coding system) is shown
along with them.

> Note that using the popup phrase wheel causes the >>codes<< to 
> automatically be supplied to the user.
> ... new language, saved, then presented, too ...
> easier and quicker and quicker to fill in the lines, as we tend to 
> describe things the same way all the time.
I would not tie the phrase wheel to codes but rather to
the narrative. To find more matches, however, one could map
narrative input -> code -> more previous narrative and present
that, too. Using the phrase wheel to speed up input isn't
dependant on using codes. But codes could provide more
matches.

> To attach the ICPC code to the SOAP lines is incredibly quick and simply 
> as one simply parses out each line into an array, using the de-limiter, 
> here a ';' key, and compares to the ICPC stuff.
Well, sure, that's the way to go.

> If not present it is 
> dealt with appropriately as 'not coded'.
Eg. left as is, eg. not code rows linked to the narrative row.

> Malcolm Ireland and I back in 
> 1996 developed a user extensible ICPC coding system where the user could 
> equate synonyms of their own to the ICPC codes in a separate module.
Which would automatically happen in GnuMed courtesy of code
rows being linked to narrative rows. We wouldn't mess with the
coding system base tables at all (they reside in the reference
service (a good candidate for early xml-rpc black-boxing)) but
rather merge their content with the previously used content as
you describe.

> I would emphasise here again, it is vitally important that we use some 
> sort of delimiter for the reasons outlined above. It speeds up data 
> entry and parsing by a huge factor.
I understand this to mean taking the design decision that
phrases that are to be understood as such are to be delimited
by the user on purpose ? Eg. not crossing delimiter-marked
phrase boundaries when looking for matches. Yes, that does
speed up things.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346