Re: RODS vs. OpenEMed, was Re: Open source medical survellance
Re Java applet, browser side. There's going to be strong opinions on this, probably on both sides. But at the CDC we made a strong stab with Java applets for several years and it never stopped being a problem. The last major push was with DataFerrett that was co-developed with Census. Census eventually wrapped it up as a standalone app and made that their recommended way to download and run the app. Some bad assumptions: - All users will have a java enabled browser, or ... - if a user doesn't have a java applet their company/gov/agency will let them download and install a java jvm for their browser, and ... - the jvm supported by a user's browser is version X.X or above. These factors can be controlled for in an intranet but not out in the world at large, particularly when dealing with tightly controlled user systems. (following is a paraphrase of an old song) Oh trouble, trouble won't you set me free? I've seen your face and I don't want to see it again. Heitzso Wayne Wilson wrote: Tim Churches wrote: But if you are looking for a fairly fully-featured map browser which can run in a browser (if you have Java), then it looks like the goods. We plan to re-assess in a year or two, when we can rely on users having a fairly recent Java VM installed. I am wondering how this evaluation can be made. We are faced with similar problems in considering the use of java webstart. Not so long ago, we had hoped that advancing browser technology would solve this problem, but Microsoft essentially killed that plan. Java is now essentially decoupled from the browser. On the Macintosh we waited for many years for Apple and Sun to deliver a well supported java with the OS and now it's happened with OS X just in time for java support to be completely dropped by Microsoft. That essentially leaves a web initiated, JRE install as the only viable option for ensuring java on client platforms that one does not control. I wonder if that option is at all viable? If it is, then what is the set of circumstances that would allow one to conclude it is ready to use? Some factors I can think of: 1) Speed of CPU 2) Rev level of OS (i.e. Windows XP or Mac OS X or linux kernel 2.4.x) 3) Desktop image policies (i.e. user can't install software) 4) Network firewall port restrictions. (We recently encountered a situation at UCLA where client browsers could not specify port numbers which lead to a failure of our clincial trials software).
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
OIO-1.0.x works with either PostgreSQL or Oracle. It is a 2-minute click-and-play install on either. What is the big deal? I suspect there's a difference in complexity. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
I agree generally with this statement. However OpenMap, for example, doesn't require this if you use it on the serverside (much like ArcIMS is typically used). We have had almost as much trouble, though, dealing with variations in JavaScript in the browser and you will find many web sites that have custom JavaScript for each browser they support.We've recently had a problem with the JavaScript interface to an ArcIMS server, too, because it makes some assumptions that may only apply on an intranet. We rely heavily on Java on the server side, and no Java on the client. We give up functionality, in many cases, but people seem more comfortable with this solution, and this option is getting better all the time with XML, etc. capabilities. I think Java WebStart is a good way to drop a Java app onto a desktop and maintain it. The fact that MS doesn't provide a JVM is actually good, because you have much more control over compatibility without it getting in the way. Firewall issues are always a problem. To have a distributed app working between enterprises, we have to negotiate with all the parties for a port (or ports) for our application. Coming over port 80 (or 843) is not a good option because this doesn't really help security. This really is a more general issue than the JVM problem, however. Installing a JVM on a system today enables the plugins for the browsers pretty much automatically, so once this is done, you are in good shape. We also have quite successfully use InstallAnywhere, which basically makes the JVM disappear, because it is delivered with the app, if needed. It is a waste, however, if each app on your desktop has its own JVM. Dave At 08:13 AM 11/6/2003, Heitzso wrote: Re Java applet, browser side. There's going to be strong opinions on this, probably on both sides. But at the CDC we made a strong stab with Java applets for several years and it never stopped being a problem. The last major push was with DataFerrett that was co-developed with Census. Census eventually wrapped it up as a standalone app and made that their recommended way to download and run the app. Some bad assumptions: - All users will have a java enabled browser, or ... - if a user doesn't have a java applet their company/gov/agency will let them download and install a java jvm for their browser, and ... - the jvm supported by a user's browser is version X.X or above. These factors can be controlled for in an intranet but not out in the world at large, particularly when dealing with tightly controlled user systems. (following is a paraphrase of an old song) Oh trouble, trouble won't you set me free? I've seen your face and I don't want to see it again. Heitzso Wayne Wilson wrote: Tim Churches wrote: But if you are looking for a fairly fully-featured map browser which can run in a browser (if you have Java), then it looks like the goods. We plan to re-assess in a year or two, when we can rely on users having a fairly recent Java VM installed. I am wondering how this evaluation can be made. We are faced with similar problems in considering the use of java webstart. Not so long ago, we had hoped that advancing browser technology would solve this problem, but Microsoft essentially killed that plan. Java is now essentially decoupled from the browser. On the Macintosh we waited for many years for Apple and Sun to deliver a well supported java with the OS and now it's happened with OS X just in time for java support to be completely dropped by Microsoft. That essentially leaves a web initiated, JRE install as the only viable option for ensuring java on client platforms that one does not control. I wonder if that option is at all viable? If it is, then what is the set of circumstances that would allow one to conclude it is ready to use? Some factors I can think of: 1) Speed of CPU 2) Rev level of OS (i.e. Windows XP or Mac OS X or linux kernel 2.4.x) 3) Desktop image policies (i.e. user can't install software) 4) Network firewall port restrictions. (We recently encountered a situation at UCLA where client browsers could not specify port numbers which lead to a failure of our clincial trials software).
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
And the fact that an Oracle installation probably already exists with an experienced DBA. With that resource, it may not be to difficult. But installing and managing Oracle from scratch is not recommend, while the same is not true for MySQL, for example. Dave At 08:21 AM 11/6/2003, Karsten Hilbert wrote: OIO-1.0.x works with either PostgreSQL or Oracle. It is a 2-minute click-and-play install on either. What is the big deal? I suspect there's a difference in complexity. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Live OIO
Just requesting MD5s at the same place that the downloads avail from, whether SourceForge or the mirrors. If they are there and close and I didn't see them then I apologize. I looked at the mirror site I was downloading from and where there would typically be a blat.md5 I didn't find one. Reason I ask is I am now downloading Live OIO latest for the second time. First time I burned a CD and tried to boot off it on two boxes that can boot [G|K]noppix and other live cds fine to no avail. I assume the download glitched though w/o md5 I don't really know. Thanks, Heitzso
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
Thanks David, Your response is balanced and gives depth to the issue. David Forslund wrote: I agree generally with this statement. However OpenMap, for example, doesn't require this if you use it on the serverside (much like ArcIMS is typically used). We have had almost as much trouble, though, dealing with variations in JavaScript in the browser and you will find many web sites that have custom JavaScript for each browser they support.We've recently had a problem with the JavaScript interface to an ArcIMS server, too, because it makes some assumptions that may only apply on an intranet. We rely heavily on Java on the server side, and no Java on the client. We give up functionality, in many cases, but people seem more comfortable with this solution, and this option is getting better all the time with XML, etc. capabilities. I think Java WebStart is a good way to drop a Java app onto a desktop and maintain it. The fact that MS doesn't provide a JVM is actually good, because you have much more control over compatibility without it getting in the way. Firewall issues are always a problem. To have a distributed app working between enterprises, we have to negotiate with all the parties for a port (or ports) for our application. Coming over port 80 (or 843) is not a good option because this doesn't really help security. This really is a more general issue than the JVM problem, however. Installing a JVM on a system today enables the plugins for the browsers pretty much automatically, so once this is done, you are in good shape. We also have quite successfully use InstallAnywhere, which basically makes the JVM disappear, because it is delivered with the app, if needed. It is a waste, however, if each app on your desktop has its own JVM. Dave At 08:13 AM 11/6/2003, Heitzso wrote: Re Java applet, browser side. There's going to be strong opinions on this, probably on both sides. But at the CDC we made a strong stab with Java applets for several years and it never stopped being a problem. The last major push was with DataFerrett that was co-developed with Census. Census eventually wrapped it up as a standalone app and made that their recommended way to download and run the app. Some bad assumptions: - All users will have a java enabled browser, or ... - if a user doesn't have a java applet their company/gov/agency will let them download and install a java jvm for their browser, and ... - the jvm supported by a user's browser is version X.X or above. These factors can be controlled for in an intranet but not out in the world at large, particularly when dealing with tightly controlled user systems. (following is a paraphrase of an old song) Oh trouble, trouble won't you set me free? I've seen your face and I don't want to see it again. Heitzso Wayne Wilson wrote: Tim Churches wrote: But if you are looking for a fairly fully-featured map browser which can run in a browser (if you have Java), then it looks like the goods. We plan to re-assess in a year or two, when we can rely on users having a fairly recent Java VM installed. I am wondering how this evaluation can be made. We are faced with similar problems in considering the use of java webstart. Not so long ago, we had hoped that advancing browser technology would solve this problem, but Microsoft essentially killed that plan. Java is now essentially decoupled from the browser. On the Macintosh we waited for many years for Apple and Sun to deliver a well supported java with the OS and now it's happened with OS X just in time for java support to be completely dropped by Microsoft. That essentially leaves a web initiated, JRE install as the only viable option for ensuring java on client platforms that one does not control. I wonder if that option is at all viable? If it is, then what is the set of circumstances that would allow one to conclude it is ready to use? Some factors I can think of: 1) Speed of CPU 2) Rev level of OS (i.e. Windows XP or Mac OS X or linux kernel 2.4.x) 3) Desktop image policies (i.e. user can't install software) 4) Network firewall port restrictions. (We recently encountered a situation at UCLA where client browsers could not specify port numbers which lead to a failure of our clincial trials software).
RE: Academic Medical Center Posistion paper
I would very interested in that discussion. We have developed some OSS apps and have used several in the realm of radiology. Maybe we can get together at AMIA. I am also putting on a symposium at the RSNA on Open Source and its role in innovation. Paul Paul Nagy, Ph.D. Director, Radiology Informatics Laboratory Medical College of Wisconsin 9200 W. Wisconsin Ave Milwaukee, Wi 53226 Http://clubpacs.mcw.edu Ph (414) 805-2167 Fx (414) 259-7889 -Original Message- From: Wayne Wilson [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2003 7:53 AM To: openhealth-list @ minoru-development . com Subject: Academic Medical Center Posistion paper I am preparing a position paper on FOSS in academic medical centers. Or course it is focused on my institution, The Univeristy of Michigan Medical School. I am interested in any FOSS projects at Medical Schools throughout the world, that is projects that are supported by the Schools as part of their academic mission. I want to list them and perhaps engage with their leaders in some dialogue about what value FOSS provides to their instituition. -- Wayne Wilson An attachment containing my pgp-signature is included. My public key fingerprint is: 9325 05AD 866B BCCB 45BF E86A 63E1 C6ED 4130 5461 My public key can be downloaded from wwwkeys.us.pgp.net
Re: Live OIO
Heitzso, Sorry that it is not obvious where to find this md5sum: http://sourceforge.net/project/shownotes.php?release_id=189288 It is part of the release notes in Sourceforge's file area. Click on the book icon for LiveOIO-1.0.6 immediately above the LiveOIO-1.0.6.iso download link. Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org On Thu, 6 Nov 2003, Heitzso wrote: Just requesting MD5s at the same place that the downloads avail from, whether SourceForge or the mirrors. If they are there and close and I didn't see them then I apologize. I looked at the mirror site I was downloading from and where there would typically be a blat.md5 I didn't find one. Reason I ask is I am now downloading Live OIO latest for the second time. First time I burned a CD and tried to boot off it on two boxes that can boot [G|K]noppix and other live cds fine to no avail. I assume the download glitched though w/o md5 I don't really know. Thanks, Heitzso
RE: Academic Medical Center Posistion paper
At AMIA next week, there are several sessions on Open Source including a fairly general panel (S89) on Wednesday morning The issue you describe is quite appropriate for that panel (in which I am a participant). Please bring the topic up, if it isn't addressed by the panelists. Dave At 09:15 AM 11/6/2003, Paul Nagy wrote: I would very interested in that discussion. We have developed some OSS apps and have used several in the realm of radiology. Maybe we can get together at AMIA. I am also putting on a symposium at the RSNA on Open Source and its role in innovation. Paul Paul Nagy, Ph.D. Director, Radiology Informatics Laboratory Medical College of Wisconsin 9200 W. Wisconsin Ave Milwaukee, Wi 53226 Http://clubpacs.mcw.edu Ph (414) 805-2167 Fx (414) 259-7889 -Original Message- From: Wayne Wilson [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 06, 2003 7:53 AM To: openhealth-list @ minoru-development . com Subject: Academic Medical Center Posistion paper I am preparing a position paper on FOSS in academic medical centers. Or course it is focused on my institution, The Univeristy of Michigan Medical School. I am interested in any FOSS projects at Medical Schools throughout the world, that is projects that are supported by the Schools as part of their academic mission. I want to list them and perhaps engage with their leaders in some dialogue about what value FOSS provides to their instituition. -- Wayne Wilson An attachment containing my pgp-signature is included. My public key fingerprint is: 9325 05AD 866B BCCB 45BF E86A 63E1 C6ED 4130 5461 My public key can be downloaded from wwwkeys.us.pgp.net David W. Forslund[EMAIL PROTECTED] Computer and Computational Scienceshttp://www.acl.lanl.gov/~dwf Los Alamos National LaboratoryLos Alamos, NM 87545 505-663-5218FAX: 505-663-5225
Re: Academic Medical Center Posistion paper
David Forslund wrote: At AMIA next week, there are several sessions on Open Source including a fairly general panel (S89) on Wednesday morning The issue you describe is quite appropriate for that panel (in which I am a participant). Please bring the topic up, if it isn't addressed by the panelists. I only wish I could go to AMIA, budget cuts in the state have restricted travel severly on the professional staff side. I think the faculty havn't seen as much reduction as they can get grant funding for it. -- Wayne Wilson An attachment containing my pgp-signature is included. My public key fingerprint is: 9325 05AD 866B BCCB 45BF E86A 63E1 C6ED 4130 5461 My public key can be downloaded from wwwkeys.us.pgp.net pgp0.pgp Description: PGP signature
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
On Fri, 2003-11-07 at 02:39, David Forslund wrote: I agree generally with this statement. However OpenMap, for example, doesn't require this if you use it on the serverside (much like ArcIMS is typically used). Yes, that's (mostly) how we use ArcIMS. I don't recall evaluating OpenMap on the server-side only - perhaps we overlooked that - we must revisit it soon. Anyway, ArcIMS is working well for us but it is a barrier to transplanting our system to other settings, since everything else is open source. We have had almost as much trouble, though, dealing with variations in JavaScript in the browser and you will find many web sites that have custom JavaScript for each browser they support.We've recently had a problem with the JavaScript interface to an ArcIMS server, too, because it makes some assumptions that may only apply on an intranet. We rely heavily on Java on the server side, and no Java on the client. We give up functionality, in many cases, but people seem more comfortable with this solution, and this option is getting better all the time with XML, etc. capabilities. Yes, we aim to be both JavaScript-free and Java-free on the client side. The GIS aspects are the only place where this has not been possible. I should say, we aim not to require JavaScript. If it is present in a known browser implementation then we are starting to use it a bit, very selectively. for some convenience functions. But if it is not available, everything still works. I think Java WebStart is a good way to drop a Java app onto a desktop and maintain it. The fact that MS doesn't provide a JVM is actually good, because you have much more control over compatibility without it getting in the way. Firewall issues are always a problem. To have a distributed app working between enterprises, we have to negotiate with all the parties for a port (or ports) for our application. Coming over port 80 (or 843) is not a good option because this doesn't really help security. This really is a more general issue than the JVM problem, however. Every time there is a MS Windows virus outbreak the network admins lock down all ports except 25 and 80 on our WAN routers and firewalls. Well, that's an exaggeration but it often happens. Installing a JVM on a system today enables the plugins for the browsers pretty much automatically, so once this is done, you are in good shape. The battle is getting IT support staff to recognise that a recent JVM should be part of their standard PC operating environment. Tim C We also have quite successfully use InstallAnywhere, which basically makes the JVM disappear, because it is delivered with the app, if needed. It is a waste, however, if each app on your desktop has its own JVM. Dave At 08:13 AM 11/6/2003, Heitzso wrote: Re Java applet, browser side. There's going to be strong opinions on this, probably on both sides. But at the CDC we made a strong stab with Java applets for several years and it never stopped being a problem. The last major push was with DataFerrett that was co-developed with Census. Census eventually wrapped it up as a standalone app and made that their recommended way to download and run the app. Some bad assumptions: - All users will have a java enabled browser, or ... - if a user doesn't have a java applet their company/gov/agency will let them download and install a java jvm for their browser, and ... - the jvm supported by a user's browser is version X.X or above. These factors can be controlled for in an intranet but not out in the world at large, particularly when dealing with tightly controlled user systems. (following is a paraphrase of an old song) Oh trouble, trouble won't you set me free? I've seen your face and I don't want to see it again. Heitzso Wayne Wilson wrote: Tim Churches wrote: But if you are looking for a fairly fully-featured map browser which can run in a browser (if you have Java), then it looks like the goods. We plan to re-assess in a year or two, when we can rely on users having a fairly recent Java VM installed. I am wondering how this evaluation can be made. We are faced with similar problems in considering the use of java webstart. Not so long ago, we had hoped that advancing browser technology would solve this problem, but Microsoft essentially killed that plan. Java is now essentially decoupled from the browser. On the Macintosh we waited for many years for Apple and Sun to deliver a well supported java with the OS and now it's happened with OS X just in time for java support to be completely dropped by Microsoft. That essentially leaves a web initiated, JRE install as the only viable option for ensuring java on client platforms that one does not control. I wonder if that option is at all viable? If it is, then what is the set of circumstances that would allow one to conclude it is ready to use?
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
On Fri, 2003-11-07 at 02:21, Karsten Hilbert wrote: OIO-1.0.x works with either PostgreSQL or Oracle. It is a 2-minute click-and-play install on either. What is the big deal? I suspect there's a difference in complexity. As Horst points out, Oracle installation and set-up is a non-trivial task, wheeras with PostgreSQL there is almost nothing to set or tune, except for the very simple to configure authentication and the size of a few buffers if you want better performance. MySQL actually has a lot more tuning options than PostgreSQL, and takes slightly longer to set up properly in my experience. But both are probably an order of magnitude less complex to configure than Oracle. There is a positive monotonic relationship between the price of a software product and the complexity and expense involved in its configuration. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
On Fri, 2003-11-07 at 00:19, Wayne Wilson wrote: Tim Churches wrote: But if you are looking for a fairly fully-featured map browser which can run in a browser (if you have Java), then it looks like the goods. We plan to re-assess in a year or two, when we can rely on users having a fairly recent Java VM installed. I am wondering how this evaluation can be made. We are faced with similar problems in considering the use of java webstart. Not so long ago, we had hoped that advancing browser technology would solve this problem, but Microsoft essentially killed that plan. Java is now essentially decoupled from the browser. On the Macintosh we waited for many years for Apple and Sun to deliver a well supported java with the OS and now it's happened with OS X just in time for java support to be completely dropped by Microsoft. That essentially leaves a web initiated, JRE install as the only viable option for ensuring java on client platforms that one does not control. I wonder if that option is at all viable? If it is, then what is the set of circumstances that would allow one to conclude it is ready to use? Some factors I can think of: 1) Speed of CPU 2) Rev level of OS (i.e. Windows XP or Mac OS X or linux kernel 2.4.x) 3) Desktop image policies (i.e. user can't install software) If the application is to be used repeatedly by a smallish number of users, I think 1-3 above can be overcome (with some effort). But if the application is intended for very widespread and/or occasional use, then client-side Java is currently not viable IMHO. 4) Network firewall port restrictions. (We recently encountered a situation at UCLA where client browsers could not specify port numbers which lead to a failure of our clincial trials software). That's always a problem. Every time a new local network admin is found, the first thing they do is close all the ports on their routers to see if anyone complains, then they re-open them as required. Again that is a generalisation and I am sorry for impugning the reputation of network admins, but with the recent Windows virus/worm outbreaks, they are a nervous group of people who often act first and ask later in an effort to keep their networks functioning at all. Thus use of non-standard ports is a source of recurring problems, I think. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
Re: [Openrods-general] Re: Re: RODS vs. OpenEMed, was Re: Open source medical survellance
On Fri, 2003-11-07 at 00:11, David Forslund wrote: At 01:07 AM 11/6/2003, Tim Churches wrote: David Forslund [EMAIL PROTECTED] wrote: Have people considered openmap? (http://openmap.org) It doesn't seem to be missing much in the way of features and has been around for quite awhile. Yes, we thought it was very good. However, for our purposes, it had two problems: a) the need for Java to be available locally - we can't rely on that, and needed a Web GIS system which could also just deliver raster images to a browser and only need JavaScript. b) we couldn't see an obvious and easy way to dumb down the interface, which is a bit too complex for the casual or occasional user who wants to look at some maps in a hurry. It works fine as I understand in generating raster images to a browser if you like through a servlet. OK, we should re-evaluate it as a servlet. Sounds like Java was the real barrier for you. Well, yes, our experience with both client-side and server side Java apps has not been a happy one - mostly the fault of the (non open source) Java GIS application we were trying to deploy. We eventually abandoned the project due to problems with massive memory consumption on both the client and server side which the application provider never managed to solve, as well as very poor client-side performance (even on the latest PCs). But yes, if we can use Python (with C extension modules for extra speed if really required) instead of Java, then we will. To us, Python is a nicer, more productive language, the execution speed is comparable to Java (much better with C extension modules for bottlenecks), Python is easier to interface with other non-Java systems (and with Java systems via Jython), and has equivalent cross-platform support to Java. What Python lacks is massive backing by large corporations such as IBM and Sun, as well as any recognition by corporate IT people. We have not found either of these to be major problems. Tim C But if you are looking for a fairly fully-featured map browser which can run in a browser (if you have Java), then it looks like the goods. We plan to re-assess in a year or two, when we can rely on users having a fairly recent Java VM installed. Tim C Dave At 08:01 PM 11/5/2003, Heitzso wrote: Re FOSS GIS, I've played with mapserver/postgis and was very impressed. I'm curious if that combination was explored, and what is available in ESRI and is used by these surveillance packages and that isn't available in current (may be the operative word) mapserver/postgis/geos/r combo (i.e. postgresql extended with postgis/geos and r statistical package)? Thanks, Heitzso Tim Churches wrote: Andrew Ho [EMAIL PROTECTED] wrote: I would hope OpenEMed is packaged for easier installation than RODS: From http://www.health.pitt.edu/rods/sw/default.htm --- begin quote WARNING! Installation of RODS and its associated software packages requires the assistance of an experienced Oracle DBA, web server administrator, and an ESRI expert. Attempting to install RODS without such guidance is not advised. --- end quote The RODS people are just being realistic. You need to understand the nature of biosurveillance systems like RODS or OpenEMed, Andrew. They are not standalone packages, but rather comprise many separate parts, all working together, and as Dave has said, interfacing with often dozens of disparate external health information systems. I suspect that in a real-life deployment, it may take many person-weeks or even person-months to properly install, configure and test something like RODS. So even for a simplified demo system, allotting several person days is not unreasonable. Just because no money is needed to obtain FOSS doesn't mean that no money or other resources are required to install and configure it. Also, they are still dependent on ESRI's proprietary GIS product. Although the various open source GIS products are improving rapidly, none currently approach the combination of power and ease-of-use of the ESRI ArcIMS product on Posix platforms (MapInfo, the main ESRI competitor, is also powerful and easy to use, but it is mainly for Windows platforms). We looked at the FOSS GIS alternatives very carefully before deciding to go with ESRI. So I can understand RODS' decision to use the ESRI product - there is no real FOSS alternative with the same range of features and capabilities. Maybe in a year or two more there will be, but not yet. On the other hand, 31 of the 50 states in the U.S. currently use RODS! http://openrods.sourceforge.net/index.php?page=contribute Yes, but only to track pharmacy sales, not for ambulatory care surveillance, which is a lot more complex. Only two states use RODS
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
On Thu, 2003-11-06 at 14:01, Heitzso wrote: Re FOSS GIS, I've played with mapserver/postgis and was very impressed. I'm curious if that combination was explored, and what is available in ESRI and is used by these surveillance packages and that isn't available in current (may be the operative word) mapserver/postgis/geos/r combo (i.e. postgresql extended with postgis/geos and r statistical package)? Yes, we have used postgis and it is great, and a very viable alternative to ESRI's ArcSDE product (which needs Oracle or DB2 from memory). Likewise the geostatistical tools for R (there are several libraries) look great, although we haven't used them much yet. We did look at MapServer and were impressed, although it is even better now. However, we though at the time (a year ago) that the amount of effort required to set up MapServer with PostGIS was more than we could manage at the time. But yes, we are keen to re-evaluate. We would be even keener to collaborate with others who are working with Mapserver and PostGIS. We are quite happy to run MapServer/PostGIS alongside ArcIMS as a comparison. Tim C Thanks, Heitzso Tim Churches wrote: Andrew Ho [EMAIL PROTECTED] wrote: I would hope OpenEMed is packaged for easier installation than RODS: From http://www.health.pitt.edu/rods/sw/default.htm --- begin quote WARNING! Installation of RODS and its associated software packages requires the assistance of an experienced Oracle DBA, web server administrator, and an ESRI expert. Attempting to install RODS without such guidance is not advised. --- end quote The RODS people are just being realistic. You need to understand the nature of biosurveillance systems like RODS or OpenEMed, Andrew. They are not standalone packages, but rather comprise many separate parts, all working together, and as Dave has said, interfacing with often dozens of disparate external health information systems. I suspect that in a real-life deployment, it may take many person-weeks or even person-months to properly install, configure and test something like RODS. So even for a simplified demo system, allotting several person days is not unreasonable. Just because no money is needed to obtain FOSS doesn't mean that no money or other resources are required to install and configure it. Also, they are still dependent on ESRI's proprietary GIS product. Although the various open source GIS products are improving rapidly, none currently approach the combination of power and ease-of-use of the ESRI ArcIMS product on Posix platforms (MapInfo, the main ESRI competitor, is also powerful and easy to use, but it is mainly for Windows platforms). We looked at the FOSS GIS alternatives very carefully before deciding to go with ESRI. So I can understand RODS' decision to use the ESRI product - there is no real FOSS alternative with the same range of features and capabilities. Maybe in a year or two more there will be, but not yet. On the other hand, 31 of the 50 states in the U.S. currently use RODS! http://openrods.sourceforge.net/index.php?page=contribute Yes, but only to track pharmacy sales, not for ambulatory care surveillance, which is a lot more complex. Only two states use RODS for Emergency Room-based surveillance so far - still an impressive acheivement, mind you. If each state contributes 0.5 developer, they would have 15 FTE developers - Wow! Yup, there is a lot of potential in FOSS-mediated resource aggregation. Tim C -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
RES: RODS vs. OpenEMed, was Re: Open source medical survellance
Title: RES: RODS vs. OpenEMed, was Re: Open source medical survellance Dear Friends, Please, I would like to unsubscribe that list. Who could help me? Thanks, Adélio Received: from jade.hcpa.ufrgs.br (jade.hcpa [10.252.252.252]) by alpha.hcpa with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VVH0CM8F; Thu, 6 Nov 2003 17:37:01 -0200 Received: from localhost (localhost [127.0.0.1]) by jade.hcpa.ufrgs.br (Postfix) with ESMTP id C443826AC6 for [EMAIL PROTECTED]; Thu, 6 Nov 2003 17:36:57 -0200 (EDT) Received: from jade.hcpa.ufrgs.br ([127.0.0.1]) by localhost (jade [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09804-06 for [EMAIL PROTECTED]; Thu, 6 Nov 2003 17:36:56 -0200 (EDT) Received: from dhaame.pair.com (dhaame.pair.com [209.68.1.163]) by jade.hcpa.ufrgs.br (Postfix) with SMTP id 0479226A9D for [EMAIL PROTECTED]; Thu, 6 Nov 2003 17:36:51 -0200 (EDT) Received: (qmail 98413 invoked by uid 800); 6 Nov 2003 19:36:18 - Resent-Date: 6 Nov 2003 19:36:18 - Resent-Cc: recipient list not shown: ; Subject: Re: RODS vs. OpenEMed, was Re: Open source medical survellance From: Tim Churches [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: openhealth-list @ minoru-development . com [EMAIL PROTECTED] Cc: openrods-general @ lists . sourceforge . net [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary==-sYr6VKN3mlvXxuxrg3a+ Organization: Totally disorganised Message-Id: [EMAIL PROTECTED] Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 07 Nov 2003 06:33:00 +1100 Resent-Message-ID: [EMAIL PROTECTED] Resent-From: [EMAIL PROTECTED] X-Mailing-List: [EMAIL PROTECTED] archive/latest/9904 X-Loop: [EMAIL PROTECTED] Precedence: list Resent-Sender: [EMAIL PROTECTED] --=-sYr6VKN3mlvXxuxrg3a+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable --=-sYr6VKN3mlvXxuxrg3a+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part --=-sYr6VKN3mlvXxuxrg3a+-- -- Adélio -Mensagem original- De: Tim Churches [mailto:[EMAIL PROTECTED]] Enviada em: quinta-feira, 6 de novembro de 2003 17:33 Para: openhealth-list @ minoru-development . com Assunto: Re: RODS vs. OpenEMed, was Re: Open source medical survellance On Thu, 2003-11-06 at 14:01, Heitzso wrote: Re FOSS GIS, I've played with mapserver/postgis and was very impressed. I'm curious if that combination was explored, and what is available in ESRI and is used by these surveillance packages and that isn't available in current (may be the operative word) mapserver/postgis/geos/r combo (i.e. postgresql extended with postgis/geos and r statistical package)? Yes, we have used postgis and it is great, and a very viable alternative to ESRI's ArcSDE product (which needs Oracle or DB2 from memory). Likewise the geostatistical tools for R (there are several libraries) look great, although we haven't used them much yet. We did look at MapServer and were impressed, although it is even better now. However, we though at the time (a year ago) that the amount of effort required to set up MapServer with PostGIS was more than we could manage at the time. But yes, we are keen to re-evaluate. We would be even keener to collaborate with others who are working with Mapserver and PostGIS. We are quite happy to run MapServer/PostGIS alongside ArcIMS as a comparison. Tim C Thanks, Heitzso Tim Churches wrote: Andrew Ho [EMAIL PROTECTED] wrote: I would hope OpenEMed is packaged for easier installation than RODS: From http://www.health.pitt.edu/rods/sw/default.htm --- begin quote WARNING! Installation of RODS and its associated software packages requires the assistance of an experienced Oracle DBA, web server administrator, and an ESRI expert. Attempting to install RODS without such guidance is not advised. --- end quote The RODS people are just being realistic. You need to understand the nature of biosurveillance systems like RODS or OpenEMed, Andrew. They are not standalone packages, but rather comprise many separate parts, all working together, and as Dave has said, interfacing with often dozens of disparate external health information systems. I suspect that in a real-life deployment, it may take many person-weeks or even person-months to properly install, configure and test something like RODS. So even for a simplified demo system, allotting several person days is not unreasonable. Just because no money is needed to obtain FOSS doesn't mean that no money or other resources are required to install and configure it. Also, they are still dependent on ESRI's proprietary GIS product. Although the various open source GIS products are improving rapidly, none currently approach the combination of power and
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
few buffers if you want better performance. MySQL actually has a lot more tuning options than PostgreSQL, and takes slightly longer to set up properly in my experience. But both are probably an order of magnitude less complex to configure than Oracle. I was suspecting a difference in the complexity of the setup on Oracle that is required by OpenRODS and OIO, respectively. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: RODS vs. OpenEMed, was Re: Open source medical survellance
On Fri, 07 Nov 2003 05:59, Tim Churches wrote: to keep their networks functioning at all. Thus use of non-standard ports is a source of recurring problems, I think. The solution is obviously applying for standardization of a port and making it widely known, at least within your audience domain. Tedious process, I sent my application for the drugref interaction server port several months ago and still no response, but I still think this is the way to go. Horst -- A non-free program is a predatory social system that keeps people in a state of domination and division, and uses the spoils to dominate more. -- Richard Stallman
simplify complexity, was Re: RODS vs. OpenEMed, was Re: Open source medical survellance
On Thu, 6 Nov 2003, Karsten Hilbert wrote: ... more tuning options than PostgreSQL, and takes slightly longer to set up properly in my experience. But both are probably an order of magnitude less complex to configure than Oracle. I was suspecting a difference in the complexity of the setup on Oracle that is required by OpenRODS and OIO, respectively. Karsten, Complexity cannot be the entire explanation. When I can put a Knoppix CD into most PC and have it auto-configure a complex mix of video cards, storage and network devices, the power of software to manage complexity / simplify is apparent. There is no reason why we cannot build software that is much simpler to install and use - including software that use Oracle. It may take more work, but that's what R+D is all about. Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
