Re: [Gnumed-devel] Mims Annual Data for gnuMed available

[Karsten Hilbert]

> Huh? These 3 seem to overlap, I'm not sure what you mean.
I was thinking of *steps* being taken towards our "final"
architecture regarding drug data access. I was *not* thinking
of *types* of drug data access within our eventual
architecture.

The overall goal would have to be to get something using the
MIMS data fairly fast so the company sees we are working with
them.

> >1) develop your mini full PI browser based directly on the MIMS schema
I thought it might be easiest to just take the original MIMS
structure and place a browser on top of that would be
easiest/fastest.

> >2) interface Hilmar's browser via a "driver" to that structure
Next, I thought, it would make sense to make sure Hilmar's
generic browser can interface the original MIMS structure via
an appropriate driver. This could well be the only driver his
browser supports at the time but there should be "room" for
more. This also does not fully exploit the possibilities of
the MIMS *data* as we would still access their structure.

> >3) incorporate MIMS data into drugref and interface MIMS *data* in drugref
This would be the final step - using MIMS as a data source to
feed our own structure (eg drugref). There will eventually be
other sources, too.

For some sources, however, we will forever have to stay at
level 1) where we just interface *their* browser.

> Can I restate this more concretely?
>        1- a set of prescribing widgets which are tightly bound to their 
> datasources 
>        and thus country-specific,
That would be another approach entirely. I was thinking about
drug information browsing only, not prescribing.

> with a common external API. (so at least 3: MIMS, drugref-PBS, and AMIS)
See, this is what I was trying to approach step-wise:

1) MIMS-only targetted API
2) generic API with only MIMS driver
3) generic API with several drivers

>       2- the prescribing widget generates a dispatcher event when it wants to 
>       display
> a drug monograph, containing just the drug name a generic/brand/class 
> indicator.
>       3- this is either passed to the external program by whatever RPC 
> mechanism, 
>       or caught by one
> of several internal viewers (Hilmar's for AMIS, a MIMS one and a drugref one 
> [the latter two which IMHO should be based
> on Hilmar's work] and I would like to write one for AMH and/or Therapeutic 
> Guidelines [which can't be based on Hilmar's model,
> as they are simple file hierarchies, not SQL databases] [1]
This sounds technically logical as far as prescribing goes.

The question is: Which part do we want to focus on for 0.1.x
or 0.2. Do we want drug information browsing (low-hanging
fruit) ? Or do we want prescribing ? (*Can* we at all ?) The
thing is that prescribing involves a whole basket of other
dependant things. In Germany you cannot usefully write a
prescribing widget unless you implement capturing billing
information, too (not bills but payour information).

> Obvious 1/ is post 0.1, but we want to demonstrate 2/ and 3/, I'm not sure 
> how, maybe a fake prescribing widget
> with just a "Drug" textbox and a "Show Monograph" button?
I am wary of anything fake in a release. But I get your point.
A very obviously marked FAKE prescibing widget in order to
demonstrate how we link to drug data may make sense. That
"Show Monograph" button, however, can be deveolped
independantly of a prescibing widget and is useful elsewhere.

> Yes. AMH is effectively in the latter category as they don't structure the 
> data enough to run a prescribing widget: its literally just a HTML version of 
> the 
> book.
So, effectively this amounts to a "jump-to" API, hopefully
with programmatic search/deep linking ?

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