Re: [Gnumed-devel] Fwd: re: Possible development opportunity

[Karsten Hilbert]

> i)  printed reports (mailed, and faxed when requested on a case by case basis)
Could be scanned into GnuMed if no other option available.

> ii) web-based portal
> - this is what the anticoagulation clinic secretary uses
a) one could access the page and save it into the GnuMed
   document archive
b) one could write a standalone "screenscraper" that produces
   data files from the web pages and place a button "fetch now"
   in GnuMed, this is prone to break whenever the providers
   change their web page layout too much, hitting "fetch now"
   would invoke the screen scraper and import the resulting
   data files into GnuMed

> - requires the data service technician to personally do the install 
> on one's computer
For what, like, a web browser !?!

> - drawbacks include "pull" technology
>    (someone must log-in, you never know when new data is available)
Well, any data *newer* than when the patient is right in front
of you isn't of interest :-)  And that's when you'd hit "fetch
now" if you suspect pending results to be available.

> iii) data download
> - they use HL7 and LOINC
Work to do but fine. There *are* Python HL7 libraries as far
as I know. None of them perfect but likely one of them
sufficient for the task at hand. LOINC is just a scheme for
abbreviating analysis names AFAIK. GnuMed does not care how you name
analyses, it happily imports them. It will, however, allow you
to aggregate tests with a selected range of names from a
number of labs into one logical test type. It is also
imaginable to write an integrity test (remember the integrity
demon I mentioned ?) that checks tests in the database for
LOINC naming and reports irregularities.

> but are switching their connection protocol 
> (sorry if it's the wrong term) to SSL VPN,
The standalone fetcher would have to support SSL. Python's
urllib2 does. The fetcher would dump to local files. An
importer would then import the files into GnuMed. Or the
fetcher could. But separation of concerns seems good.

> approaches to this point 
> have involved loading the results directly into one's data tables and 
> not a file download. I will pursue getting further details.
That's how their fetcher+importer all-in-one works. It needn't
work like that for us. But it can, too.

> A hand entry screen will still be important.
Could IMO be solved with a nicely dedicated edit area.

> Local lab companies seem very uninterested in receiving lab requests 
> electronically except hand-entered into their portal which nullifies 
> the advantage of an EMR  :-(
It doesn't nullify the advantages for "us", does it ?

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