Re: [openhealth] Re: List future [was: Why are you here?]
Completely off topic and hence off list reply ... thanks for the image. I often talk about how management or a new manager needs to pee on the bush (make his/her mark?) and its best just to understand that the ancient ape stuff needs to happen ... Anyway, thanks for a morning smile. Thank you, Brian. What we need to do I think is to all have dinner together one day. An academic and political programme is of course important, but so is the ancient ape stuff. In the absence of that large dinner, let us all behave as if we had been to it, and thus had done the H. Sapiens equivalent of sitting around picking lice out of each other's fur - you know, been introduced. This has been called building a community, but I think we sometimes take ourselves too seriously.
small practice management programs
Anyone know the current status of open source small practice management programs? Or what web sites that monitor open source health programs are current? Thanks, Heitzso
Re: M$oft Word to XML or HTML conversion
Daniel L. Johnson wrote: Dear All, Anybody here know of a tool to convert MicroSoft Word files to XML or HTML? We have a huge archive of Word files... Thanks, Dan Johnson md antiword does a reasonable job in batch mode (cygwin, other sources) then there are a couple txt2html variants, the one's I've tried do a reasonable job
Re: Open source tools for population health epidemiology and public health
Side note re limited to non-Windows by postgresql. I've often run cygwin postgresql and, while it takes a few minutes to setup, has run fine for me. I've read elsewhere of people having stability problems with that env but have not encountered any on my end. I don't know if the stability problems with cygin/postgres have been resolved or if my db apps just haven't stressed postgres enough to hit a cygin/postgres instability. I ack that the native flavor postgres should be much faster than cygin indirection flavor, but whether that's a problem or not is dependent on amount of data and desired response time. Just a note. And, yes, native postgres 8.x should be out shortly. Cheers, Heitzso
Re: web based applications and PRINTING
Web printing 'was' notorious difficult for quite awhile, from the developer's point of view as well as the user's. The primary reason was at first the lack of tools at the disposition of the webscreen designer, then later, the lack of faithful implementation of CSS (cascading style sheets) standards by the browser makers (ie, IE). This technical hurdle doesn't really exist anymore since (most) standards are fairly well integrated now and new ones have evolved rapidly to keep pace with needs. Couple of months ago I tried to use CSS instead of nested tables to control simple text placement. No way could I do that -- then current (Aug '04) IE and Mozilla (also tested Opera) implemented basic CSS text positioning differently. Hair pulling out time and/or beating head against wall time. I'm guessing everyone is still using nested tables to position text as a least common denominator instead of doing it the correct CSS way. Anyway, I'm flagging that CSS is not at all implemented consistently across browsers. I'm not saying that by using some subset of CSS that you couldn't get it to work to print pretty pages, but if you go into CSS cold with a book in hand about how you are supposed to format pages with CSS be prepared for a rude awakening. Heitzso
simple medical/social data collection question
Last night I went for a walk with two friends. One used to work at an abuse center that wants to computerize standard data collection which is now just paper forms. This would also entail centralized collection of reportable data, etc. The other works as a the head nurse in a hospital section (stomache stapling) where there was no tracking of return visits due to complications. For the time being she's setup, on her own initiative, a simple spreadsheet program to get those stats but ultimately may want to move to something more flexible than a spreadsheet program. Note that these are very simple apps from the perspective of the potential users. They don't want a full EMR database. On the other hand I don't believe the potential users have thought through security/privacy issues, patient ids, etc. In other words all of the stuff that comes up after the first cut into the app. In either case there is very limited funds for development. I'd like to do some homework re the systems worked on by individuals on this list to get a sense of how much time would be required to setup these systems. So, current recommendations? I know this is an awkward question because I am so nebulous in my spec. I apologize. Don't waste a lot of time answering my question, just a few pointers and fast comments would be appreciated. Thanks, Heitzso
Re: hand drawn diagrams stored in a medical record app?
I've been looking through my EHR/EMR bookmarked URLs and noticed that TORCH allows someone to upload a JPG. This isn't the same as marking up a simple diagram with mouse movements, but is an interesting variation. I appreciate everyone's comments on this (and the broader data collection) problem. Heitzso
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).
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: LiveOIO-1.0.0.rc2 released
I greatly appreciate a live-cd demo of a product, and the idea of being able to easily install to a computer is great. However, I have a question-caution. Do you have a clean version update and security update mechanism in place? I'm aware that knoppix is pieced from several sources and your LiveOIO will be pieced from even more sources. So my question becomes, Do you have an apt and apt-sources setup such that you can smoothly handle security and version upgrades via apt? Or, if someone installs to a computer can they easily and safely upgrade the entire setup via the 'apt-get update/upgrade' mechanism? Thanks, Heitzso Andrew Ho wrote: Dear colleagues, I have uploaded a new version of LiveOIO to Sourceforge. You can download it from http://sourceforge.net/project/showfiles.php?group_id=9295 LiveOIO-1.0.0.rc2 includes OIO-1.0.1 and an improved interface for starting the OIO Server. Instead of typing startOIO into a shell-terminal window, simply click on the OIO Server Start icon on the KDE Desktop. There is also an OIO Connect icon that launches the Mozilla browser and directly opens OIO's pink interface, without the need to manually entering the URL and username/password. The entire process of running OIO on any PC now only involves 2 mouse-clicks after booting the CD! Installing to hard-drive still only requires opening a shell-terminal window and typing knx-hdinstall. I have also included 1 form (Meeting), 1 schedule, 1 workflow, and 2 patients. I think it is helpful to include more forms on LiveOIO. Please send me forms that you think will be worthwhile including. Anything that I receive by Oct 16, 2003 will have a good chance of becoming part of LiveOIO-1.0.0. My estimate is to include somewhere between 20-30 forms. Current aim is to release LiveOIO-1.0.0.final by Oct 17, 2003 - a week from now. We have time to do .rc3 if someone finds a serious bug. Dennis Halladay's new date, date_time, time component should make it into LiveOIO-1.0.0.final. Vadim and Alex's fracture classification wizard may also make it. Per Mark's strong recommendation, Frozen-Bubble is once again included. I sacrificed the Selflinux documentation (18 mb) since it was entirely in German. :-) Best regards, Andrew
RE: On Possible Canards, or Don't forget to duck
I'm not a doctor ... work at cdc hence monitoring this list at the moment sitting in Rochester MN airport to go home, mother at Mayo in ICU, her GBS/vasculitis(still undecided) rough case w/ axonal nerve damage, kidney impairment, asceptic meningitis/stroke[s]/other enchephalitic (sp?) damage possible and ... etc. etc. Relevance to this thread is the Mayo doctors reviewed all similar cases (one? two?) with combo GBS/axonal/IVIG damage and believe possible that those cases may have been misdiagnosis of vasculitis. I believe it is crucial that the background med notes not be lost in a 'structured/coded' information representation. Nothing wrong with a top level coded representation, but the ability to dig below that simplified world view is important. Heitzso
Re: Analysis and Requirements Document - Quick Quack
Agreeing with Dr. Johnson that the core document must be one of use cases focused on what is needed to provide optimal health care. Next level down being abstract design, with discussion re a reference implementation being farther last in line. Just ack'ing that discussions re technology/implementation is a distraction if the core needs use cases and design not fleshed out. == PLEASE, A SIDE QUESTION: I'm trying desperately to sort out if there is interest in the open source world in the type of project our branch is working on, and, if so, where I would find that interest. I would greatly appreciate a few comments from this list re the appropriateness of my trying to push my project's needs into this space as well as any hints re other projects/lists that might be appropriate. Thanks. Our branch needs to query and report against distributed data sources, i.e. epidemiology research in which sickness/death correlated with race/age/sex/pop/geo along with pollution indices and other data sources (water tables, wind speed, ??). My fantasy is that the same is applicable down to the health provider in that health provider records [appropriately scrubbed or confidentiality filtered] are where you will see an outbreak first. So health provider records become a primary data source that may be combined upstream into geo/regional data stores, that are then queriable as a federated system. I _assume_ such a system would be applicable to a health provider in that information needed to aid a patient might be obtained from such a data source. As an odd example, my mother (real life) contracted Guillain Barre Syndrome from a flu shot recently and just got out of the hospital (she's able to walk, but barely). Yesterday I heard of another GB case from this year's flu shots. But when my mother first went to an emergency room she was turned away. It wasn't until she lost the ability to walk that she was correctly diagnosed and treatment started. I wonder whether access to large federated data stores of recent symtoms and diagnosis would have caught her GB on the first ER visit? Heitzso Information Technology Branch Centers for Disease Control and Prevention [EMAIL PROTECTED] or [EMAIL PROTECTED] On Sat, 2002-11-23 at 10:34, Daniel L. Johnson, MD wrote: Christian Heller wrote: I wonder if a collaboratively produced set of documents - a Wiki - may be better than a mailing list for presenting this sort of thing? Yes, a list is definitely needed to do the actual analysis, i.e. to talk about things. But the precious results of discussion are much better stored in a (set of) Requirements Document, may it be Wiki Web Pages (I had to find out about what it is at http://c2.com/cgi/wiki) or normal files. Using SGML or XML, it is possible to maintain only one document and generate many other types (txt, rtf, html, tex, dvi, ps, pdf) from it: http://www.linuxdoc.org Dear All, I would be willing to re-organize and modify the QuickQuack documents as a collaborative effort. I propose the following scheme: 1: I break will down this document into sections. After this task is completed - (2) 2: CVS is already installed on my Red Hat server; the technician who supports this server offers to configure CVS for use by trusted users; we will plan to include wrap-arounds so that the document can be viewed either as sections or as a whole. 3: Trusted users will be permitted to make commits that change the document (that's the whole purpose of doing this). Backups will of course be kept of both prior and current versions. 4: I am assuming that Molly Chean and Christian Heller would be the first trusted users. Alternative content management systems are probably too complex or fail to maintain an intact document. For example, Red Hat purchased ArsDigita, which produced content management system CCM; but this requires one server running Oracle 8xx (because of special SQL extensions required by CCM) plus a front-end machine. This is fine for Siemens, with 50,000 people, but not for us. For example, Zope began life as a content management system, and Zope bits could be used to build one for our use - squishdot does this - but I think we want to maintain an intact document, not a change list. PHILOSOPHY I think that the QuickQuack documents are a useful specification for two reasons: First, this specification is small enough for the beginning worker to wrap his or her brain around. Second, this specification defines function and ergonomics rather than data structures. Please correct me if I am wrong. Thus I see specifics such as data structures and fields off to the right of this effort, adjacent to it but not within it; and I see organizing efforts such as openEHR/GEHR as being off to the left, also adjacent but not within it. In other words, I envision the neo-QuickQuack as keeping focused
