---------- Forwarded Message ----------
Subject: Re: FreeMED and HXP Date: Wed, 17 Mar 2004 10:07:28 -0500 (EST) From: Jeffrey Buchbinder <[EMAIL PROTECTED]> To: Elpidio Latorilla <[EMAIL PROTECTED]> Cc: Irving Buchbinder <[EMAIL PROTECTED]> On Wed, 17 Mar 2004, Elpidio Latorilla wrote: > Hi Jeff, > > On Tuesday 16 March 2004 18:37, you wrote: > > 4) Physician B's system receives a login request from Physician A's > > system, using HTTPS wrapped XML-RPC with basic authentication. The > > username is emri://directory/physician_a or something like that. > > Physician B's system acquires a copy of Physician A's public key, and > > creates a challenge request. If Physician A can return the plain text of > > the challenge request (which can only be decoded with their private key) > > then access is granted. > > > > Does this sound pretty reasonable? > > This is a very bright idea. I like it. We should explore further this > matter. I see several environments where interoperative activities via the > protocol will take place. > > 1) local machine , e.g. a KDE based client like a dictation app will > communicate with Freemed or Care2x which both are php based all inside the > same machine. Btw. this is one of the reasons why we are motivated to > develop the hxp (or whatever we name it) because it will simplify > development of plug-ins. Just imagine the difficulty in creating a > dictation app with a browser! In FreeMED we have plain vanilla XML-RPC for this, since it is serious overkill to require challenge/response authentication for local users. We actually have a scanned document archival application working over XML-RPC, so it is definitely a viable solution. HXP is an internet solution, because you need to be able to interoperate large sections of patient records. It probably will include an authentication layer, so you have one of two choices: 1) Create the *option* to allow non-local clients on your XML-RPC service provider, while allowing it to still interoperate over the internet using HXP. This would be useful if you need atomic XML-RPC calls in both your standard interface and in HXP. Not sure if that's the case. 2) Have seperate XML-RPC service URLs for each. I may end up going this way, just to keep access locked down. You don't need people who are pulling and/or sending EMR chunks to be doing atomic operations on your core data... HXP should be pre-processing the data, not just passing it through unchecked to the system. > 2) Intranet, e.g. clinic or hospital where the interoperation takes place > inside a firewalled zone and the clients know each other. This is definitely a case for plain vanilla XML-RPC. No external authentication is needed, because all users are trusted. See above. > 3) Internet, well you know it. > > Your GPG concept is most probably the minimum for the internet operation. > On the other hand, it would be overkill for the local machine operation. > > So we might devise a way to make the system flexible depending on the > operation environment, but keeping the whole as simple as possible. I will > be thankful for you ideas on this matter. > > > Also, for projects which have XMLRPC services already built in, we can > > either require a seperate XML-RPC provider (as you have done in Care2x by > > creating a seperate module) or create a higher level namespace like > > EMRi.Patient.(whatever) or HXP.Patient.(whatever). > > I appreciate your idea of prepending the names of the project. But there > are several more projects, so it will soon become impractical. Also, some > other projects might feel uncomfortable in using procedures which are named > after a different project (we are also planning to launch campaigns > targetting commercial, perhaps proprietary too, applications to jump in). > I would suggest that we make the names devoid of any reference to a > particular project. This will help improve the overall acceptance. The question is whether you are doing this with atomic calls or with monolithic XML documents. If you are using XML documents, you need to parse them out, but you don't really need to extend the spec every time you need a new data point added, and systems can just drop what they don't need. However, it limits the atomic operations you can perform, although I don't really see the need for performing very tiny changes, since you can create a record "diff" and send it in a monolithic file just as easily. If you do this with XML documents, the namespace is so tiny that people don't really have to worry about the fact that the transport or authentication protocol name is prepended. Please feel free to cross post this to the HXP list. I'm working on a PDF spec for the authentication and versioning layer now. Thanks, Jeff ([EMAIL PROTECTED]) FreeMED Software Foundation http://freemedsoftware.com/ ------------------------------------------------------- ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click _______________________________________________ Hxp-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hxp-developers
