[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lab importing Re: [Gnumed-devel] Bootstrap of (test) lab data

From: Tim Churches
Subject: Re: Lab importing Re: [Gnumed-devel] Bootstrap of (test) lab data
Date: Sat, 19 Jan 2008 10:07:01 +1100
User-agent: Thunderbird (Windows/20071031)

James Busser wrote:

On 17-Jan-08, at 5:46 AM, Karsten Hilbert wrote:

Also the wiki describes LabJournal and PathLab plugins, though they are not included in the default workplace and I kept hitting an exception trying to
see if other  workplaces contained them. Are they available to test?

... as we don't have any of those two available for
end-users we cannot properly view lab data yet. That is an
area which needs a lot more work put into it.

Labs would give me the use case (after I got server support, and a backup protocol maybe using JungleDisk going) to try to use GNUmed in real life. Other people's priorities could include stabilization and debugging of what is already there in 0.2.8 / 0.2.9.

Are there any other priorities that leave me alone in my interest to get the labs more developed?

I know someone who is very Java familiar and may be able to assist any questions of how current Oscar code imports a large portion of British Columbia (BC, CA) lab data into the Oscar backend if there were value to a Python importer for this data being crafted. Would it be strategically helpful to other (non-BC) users to develop and make available a Python module to process downloaded XML data coded in LOINC or would such things be so locale-specific as to need to be written from scratch?

The alternative would be that a service might be developed with less work, in Java, to import the data into British Columbia users of GNUmed if it is reasonable for this service to not have to interact with Python middleware.

Is it recommended that instead of providing such an external (java) service with the gm-dbo password, some different user would be set up like gm-labagent to authorize this activity?

Have a look at Mirth - - which can be scripted in Java or Python and which can interface directly to database back-ends or via various APIs or Web service interfaces. Might be easier than re-inventing all this within GNUmed (or might not be). we are about to look at it in detail for interfacing NetEpi with various lab HL7 and other data feeds - happy to report our findings in a month or two.

Tim C

reply via email to

[Prev in Thread] Current Thread [Next in Thread]