Re: [Gnumed-devel] [FreeMedForms] drug code detection problem

[Karsten Hilbert]

On Wed, Oct 16, 2013 at 05:19:14PM +0200, Eric Maeker wrote:

> > Are you telling me that -- in order to *U*niquely identify
> > one drug in FreeDiams -- one needs *two* Unique identification
> > numbers ?
> 
> Nop not 2 but 3 uids. This is useful to keep drugs database the closest as 
> possible to the raw sources.
> FDA uses 2 uids, France one, Ca 2, for ZA I use 2...

I see.

However, is there really a need to burden
each and every API user with implementation
details of the internal FreeDiams database ?

IOW, when the API changes all external code
must be adjusted.

It would be much desirable to hand out and
pass back in *one* value clearly identifying
a drug. Of course, the *content* of that
value can change -- but that doesn't matter
because it is expected to be treated as an
opaque block of data.

> > What's unique about two ?
> 
> The association of the three is unique (constraint is u1::u2::u3 == unique).

That's why it makes sense to tell external code:
uid = "..." (for example "u1=...::u2=...::u3=...").

The very fact that *several* UIDs are needed to
be unique belies the very U in UID.

> > The documentation for the latest prescription XML
> > 
> >     http://www.freemedforms.com/en/manuals/freediams/prescription_fileformat
> > 
> > does not list any requirement to give two unique IDs.
> > In fact, the example does not have the second (u2="")
> > one either.
> 
> Yes if u2 / u3 are not required you just leave them empty.
>But a drug can be identified with one, two
> or a combination of three uids. This combination
> is persistent in time.

FreeDiams can certainly handle this any way it sees fit.
However, it doesn't make sense to let outside code
care about such internal technicalities.

> Why don't you just keep the FreeDiams files intact

We do.

> and return them back to FreeDiams without any internal
> modification?

We don't. However, there are situations which aren't
covered by any prescription files having been generated
by previous runs of FreeDiams:

- there is no prescription available (never called
  FreeDiams before on that patient -- GNUmed can
  still already know the drug UID)

- user deleted the old prescription file in GNUmed

- user wants to prescribe a different set of drugs
  as last time with preselection in GNUmed (say,
  textual drugs)

- user wants to include substances not handled by
  the FreeDiams database

- user wants to include arbitrary comments with
  the prescription derived from data already
  available in GNUmed

There's more but I'm sure you get the point.

> >> If you miss it, please tell me
> >> which version of FreeDiams did you use to get this uid. There
> >> was uid breaking in a previous update with FDA & CA. I did
> >> mention it earlier. Do you remember this?
> > 
> > I remember.
> > 
> > I have used the latest FreeDiams on Debian
> 

> Ok, so the problem is the uid combinaison storing inside GNUMed.

Storing is not a problem. The need to parse (and
thereby know more of FreeDiams than what's
desirable) is.

> From your side, do you keep the FreeDiams xml
> prescription file in your database?

Yes.

> If so, can you provide a script to update the drugs uids in GNUMed?

I could write a script to trawl the documents table
which holds copies of the FreeDiams prescription XML.

However, that's not the point, don't worry about that.

My point is that IMO it is not a good design to have
outside code need to worry about things like how
FreeDiams structures the information it needs to
uniquely identify a drug. In terms of outside code
there should be *one* field being passed back and
forth. If that field contains what was handed out
the drug will be found.

All in all I would like to ask for one thing:

Could FreeDiams please hand out one single

        drug_uid=""

field which will uniquely identify that drug
to itself ?  That would be really helpful.

If I *may* suggest of format for the content I
would approach it like this:

        
drug_uid="db=DB_ID::uN=...::uN+1=...::...::uN+x=...::db_oldN=old_DB_ID::oldN=...::db_oldN+1=old_DB_ID::oldN+1=...::...::db_oldN+x=old_DB_ID::oldN+x=..."

Within that structure unneeded fields could be left
out. Only problem would be if suddenly DB IDs
or drug IDs containing = or :: show up. Other than
that this should be fairly future proof.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346