[Top][All Lists]

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

[Gnumed-devel] Re: Possibility of a REST client and REST backend

From: Dave Cramer
Subject: [Gnumed-devel] Re: Possibility of a REST client and REST backend
Date: Wed, 6 Feb 2008 07:27:06 -0500

On 5-Feb-08, at 10:37 PM, James Busser wrote:

-----Original Message-----

FWIW, I think this python client (done this way) is
all wrong. Which is why I haven't replied. I'm working on trying
something else.

Your experience inside a hospital suggests that directly connecting to
the backend is going to be problematic.

I'd like to see a REST client and a REST backend.

I *would* suggest that we not make connectivity from the hospital a first priority, for a couple of reasons:
1) my office is across the street from the hospital
2) it is not impossible that I could get the hospital to unblock some ports, from at least aa couple of computer locations in the hospital 3) the machine I would use as a server has no competing need to host port 443, the server's purpose woould be purely to support the aZEMR (GNUmed) so if the GNUmed client would (via config file) go out through the hospital's proxy on port 443 and that would then, on hitting the server, get redirected to PostgreSQL, maybe that would solve any need if #1 and #2 above would not.

The bigger challenge is for everyone else. To make this a product it has to "just work".
Strategically (or at least tactically) the earlier interest is identifying how we might get the Excelleris XML-wrapped HL7 lab data into the GNUmed backend. It sounded like Richard might assist us with that in a couple of weeks.
OK, I can do this now. What I need help with is where to put the data. Is it possible for you to provide me with pseudo code which takes the Excelleris HL7 data and inserts it into the correct table?

So for the pseudo code assume you have the HL7 parsed and make up variables with HL7 ish names.


insert into foo (firstName .....) values (PID.patientFirstName....)

I gather REST has more to do with your contemplation of a full Java and/or browser-based alternative to a Python client? Dunno whether the following usefully captures the essence:
Yeah, it accomplishes much more though. All of the business logic stays in one place and you can have any client you want.


reply via email to

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