Re: Where does open source software typically come from, was Re: reportfrom OSHCA 2002 meeting
Andrew, IBM releases its development tool kit as open sourceas you have noted...Apache and the Linux Kernel are not applications like a hospital information systemyour rationale for excluding IBM as an open source developer needs a better foundation. Joseph --- J. Dal Molin e-cology corporation www.e-cology.ca Italia: (39) 0427 93006 GSM: (39) 349 434 7558 Canada: (1) 416.232.1206 - Original Message - From: Andrew Ho [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 25, 2002 12:34 AM Subject: Where does open source software typically come from, was Re: reportfrom OSHCA 2002 meeting On Sun, 24 Nov 2002, Adrian Midgley wrote: ... Typically, there is no such thing as a OSS system developer whose job is to provide solutions that fit the needs of the maintainers of these big systems! Disagree. Citing IBM as an example. Adrian, I just don't know whether IBM could count as a open-source software system developer. Bill Steagall covered mostly IBM hardware and a little about the Eclipse tool platform (www.eclipse.org). I guess when IBM produces an open source hospital information system for UCLA, your example will be appropriate. I do think so far, open source software _typically_ come from in-house development (e.g. VistA, OSCAR, TkFP, Apache, Linux kernel, OIO, GnuMed). Maybe this will change. Maybe you have some reasonable speculations on why this will change? ... Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: GnuMed's unique contribution relative to other projects, Re: report from OSHCA 2002 meeting
On Monday 25 November 2002 06:00, you wrote: What compromises for expediency are present in OIO? Glad you asked :-). We have been discussing OIO's database schema over the last week or so. The main thrust of the discussion surrounds OIO's use of lots of tables, rather than few tables with lots of rows. There seemed to me to be a larger one in the storage of forms, with the lack of a data dictionary making it unfeasible to share records across multiple systems and places. But the creation of record and form is very handy - expedient. Thrusts in the UK are toward interoperability. and this requires such dictionaries to be shared and is helped by an underlying ontology. -- From one of the Linux desktops of Dr Adrian Midgley http://www.defoam.net/
List Usage Guidelines Update
*** *** The OpenHealth Mailing List *** Terms and Conditions of Use *** 1. INTRODUCTION Please retain a copy of this message to help you with your usage of the OpenHealth mailing list. The OpenHealth mailing list is a place for health care professionals, IT professionals, and members of the public who are interested in health care and open source software to gather and discuss the issues of this field. Openhealth list areas of discussion are centred around topics related to open source issues in the health care domain including: * Deployment stories * Discussion of open source projects and products * Question and answer * Open source licences and their applicability to health care * Security and privacy issues * Obstacles for open source software in health care * Related issues 2. USING THE LIST To POST messages to this list, send your message to [EMAIL PROTECTED] To UNSUBSCRIBE from this list, send a message to [EMAIL PROTECTED] with the word UNSUBSCRIBE in the subject line. To view previously posted messages, visit the MESSAGE ARCHIVES at: http://www.mail-archive.com/openhealth-list@minoru-development.com/ More information about Minoru, OpenHealth, and open source software, is available at http://www.openhealth.com IMPORTANT: In order to help manage invalid or dormant accounts, the Openhealth mailing list servers are set to automatically unsubscribe accounts where there have been 3 sequential message delivery failures. A failed delivery can be caused by an invalid email address, a (non-existing email address), a full inbox, etc. 3. POLICIES REGARDING MESSAGE CONTENT 3.1 Copyrighted material: You may not post copyrighted material on the list outside of fair use guidelines. Private email is considered to be copyrighted by the original author. If you post private mail to the list, you must include the author's permission to reproduce the material. 3.2 Mail attachments: You may not post mail attachments to your messages. The only exception to this policy is for those messages sent from messaging systems that enclose decorative elements (such as an image of an envelope, globe, etc.) that the user cannot disable, e.g. the Lotus Notes email client. 3.3 Advertising: Advertising, or blantant sales pitches / hype is not permitted on the list. Reasonably promoting your project or goals to attract collaborators is acceptable and fair use. Commercial advertising is not permitted. 4. ETHICS AND NETIQUETTE 4.1 The list can not be used to slander or attack any company or individual. Openhealth will not be used to air problems of this nature in ANY way. This includes flaming, baiting, name calling, using profane language, accusations of illegal, immoral, or unethical activity. 4.2 You may not use addresses obtained from the Openhealth list to send offensive, abusive, or bulk commercial email (spam). 4.3 The Openhealth list is privately owned and maintained by Minoru Development Corporation as a service to the open source health care informatics community. Any individual who causes harm or mischief to the equipment, software, or processes of the list may be removed from the list at any time. 4.4 Breach of list rules may result in a private email reminder of list rules, a public (list) reminder, or suspension/removal from the list. 5. ADDITIONAL OPEN SOURCE READING MATERIAL Some of the following reading material has had an important historical impact on open source / libre (free) software. We encourage all participants of the list to be familiar with open source theory and history to get maximum benefit from the list. http://www.euspirit.org/library http://www.tuxedo.org/~esr/writings/cathedral-bazaar/index.html http://www.tuxedo.org/~esr/writings/cathedral-bazaar/homesteading/ http://www.oreilly.com/catalog/cathbaz/ http://www.openhealth.com/en/opensource.html LEGAL DISCLAIMER MINORU DEVELOPMENT CORPORATION TAKES NO RESPONSIBILITY FOR THE CONTENT OF MESSAGES POSTED ON THIS MAILING LIST. BY SUBSCRIBING TO THIS MAILING LIST, YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS EXPLAINED IN THIS MESSAGE. -- Dave Scott Minoru Development Corporation; Minoru Development SARL, the home of Openhealth(tm) 3, rue du Colonel Moll, 75017 Paris France Office: +33 (1) 30.61.18.43 Mobile: +33 (6) 89.49.01.91 Web site: http://www.openhealth.com
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
Re: Where does open source software typically come from, was Re:reportfrom OSHCA 2002 meeting
On Mon, 25 Nov 2002, Joseph Dal Molin wrote: ... IBM releases its development tool kit as open sourceas you have noted...Apache and the Linux Kernel are not applications like a hospital information system Joseph, It seems that you missed my point, which is: Where does open source software typically come from Apache, Linux, and several open source health care applications that I gave as examples all come from in-house development rather than outside vendors. That was the point that I tried to make. The fact that IBM has released some open source tools does not conflict with my statement that, so far, _open source software typically do not come from third-party open-source software developers_. your rationale for excluding IBM as an open source developer needs a better foundation. You misunderstood. see here: Adrian, I just don't know whether IBM could count as a open-source software system developer. Bill Steagall covered mostly IBM hardware and a little about the Eclipse tool platform (www.eclipse.org). I guess when IBM produces an open source hospital information system for UCLA, your example will be appropriate. My point was that IBM is not a good example of a typical open source software developer. I did say things may change - but let's get down to discussing why IBM has not released an open source health information system yet, AND what has to happen for them to take that step. my next sentence was: I do think so far, open source software _typically_ come from in-house development (e.g. VistA, OSCAR, TkFP, Apache, Linux kernel, OIO, GnuMed). Now, the really useful part of the discussion is the following: Maybe this will change. Maybe you have some reasonable speculations on why this will change? I can think of many reasons why this would be very useful (e.g. for IBM to develop open source hospital information systems). I don't think this is analogous to Microsoft producing/releasing an open source operating system. IBM will still be able to make money from providing service and selling hardware. I am most interested in your thoughts. Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: Analysis and Requirements Document - Quick Quack
On Monday 25 November 2002 18:32, Heitzso wrote: 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, ??). The Meterological office in the UK is doing some of this sort of thing in prediction from the predicted weather how the incidence of certain diseases or events will change in teh next few days, allowing hospitals to consider how close to maximaly they may use their beds etc. The Met Office is moving to Exeter very soon. Dragging the information the other way, out of an arbitrarily large number of medical record systems, is one theoretical use for the MIQUEST query generator and interpreters, whcih use HQL - a superset of a subset of SQL - Health Query Language - to raise congruent reports from each of many systems. -- From one of the Linux desktops of Dr Adrian Midgley http://www.defoam.net/
Re: Where does open source software typically come from, was Re: reportfrom OSHCA 2002 meeting
On Monday 25 November 2002 19:08, Andrew Ho wrote: Where does open source software typically come from Professional programmers working in firms that may be IT generators or IT users produce a large proportion of Open Source software. SOme of it in work time as a result of scratching an itch, some as a raction to having to make expedient compromises in their working time, some of it (locally) as a core part of their commissioned work, released as OSS for the twin reasons of philosophy and an argued practical advantage. Where did GT.M come from? In what sense is LANL a health service provider? I suppose that to develope a health -related program or element, it is necessary to have some nodding acquaintance with the world of healthcare, but I think all one can say about software is that it comes, largely, from programmers, whether professional or like me amateur, and that while the domain knowledge of the amateur can count for a lot, professionals make code faster and more prolifically than amateurs. And often righter. -- From one of the Linux desktops of Dr Adrian Midgley http://www.defoam.net/
data aggregation, Re: Analysis and Requirements Document - QuickQuack
On 25 Nov 2002, Heitzso wrote: ... Our branch needs to query and report against distributed data sources, Heitzso, There have been many attempts to solve this problem. Depending on your relationship with the data source sites and what you need from them, different solutions come to mind. 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. Most(all?) existing open-source health systems can do this. David Forslund's OpenEMed (or a closely related component), if I recall correctly, have already been deployed by the government (CDC?) in a network of emergency rooms for exactly this application. Of course, the OIO system can probably do it a little easier :-). Also, the automatic anonymization feature is part of the OIO system's design. 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. What you describe is technologically quite easy. The politics may be quite hard, however. 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 hope she is doing better now? I wonder whether access to large federated data stores of recent symtoms and diagnosis would have caught her GB on the first ER visit? This is hard to achieve. If the decision support computer is better than the doctor, it makes sense to let the computer make decisions (e.g. order some tests). On the other hand, if we are not convinced that the computer is better (than the doctor) - and force the doctor make the final decision, the machine can still end up making decisions (e.g. EKG machine with automatic analysis). Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Diagnosis of unusual illness
Heitzso wrote: 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? The sad reality is that large federated data stores have existed for years; they are called medical textbooks and they are amazingly easy and fast for the expert user -- but that we humans sometimes fail to experience that little click of cognitive dissonance that says, Whoa! Case of premature 'closure' of diagnostic thinking here! Dig deeper on this case! The large federated data store that is currently most useful to me when I hear the little click of cognitive dissonance is -- hold your breath -- google.com. If I enter proper medical jargon, I get only medical hits, and sometimes very, very helpful ones. But I have a Linux cptr hooked to a T-1 line in every exam room with a browser up and running. And the textbooks are 30 feet away, so they get consulted second. Third, I call up a smart colleague and see if he can break the mental ice. But... it all starts with the recognition that here's something strange: we docs all fall victim at one point or another to the truth that common diseases commonly occur and after a few years of looking for and not finding medical zebras, the urgency of continuing to look does abate, just as for the sentry who stands guard for years against a enemy who never shows. So it's not more data we need, it's a more perfect human; and silicon ain't gonna help. I'm sorry that your mom fell afoul of human frailty. Dan Johnson md
Re: compulsion? was Re: report from OSHCA 2002 meeting
On Mon, 25 Nov 2002, Tim Churches wrote: ... it makes sense for all publically-funded software development to be open-sourced Tim, Where would you draw the line? When the State of California buys 2000 licenses for the infamous Oracle DBMS, does that constitute providing public funding for the development of Oracle DBMS? Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Nigeria emails
Dear All, This is on-topic only to the extent that we all receive Nigerian spam. If you simply forward each of these emails, adding no loss (if appropriate to your situation) to [EMAIL PROTECTED] you will help the feds in our country keep building the pile of evidence needed to combat this scourge. Dan
Re: Diagnosis of unusual illness
At Mon, 25 Nov 2002 14:01:14 -1000 [EMAIL PROTECTED] wrote: I concur on the absolute utility of an open and questioning mind aided by the power of such tools as Google. I too have it at my fingertips and use it daily ( an excellent example for the disbelievers I come across: type in arthritis, urethritis into Google and see that the first 5 pages or so of hits are articles on Reiters syndrome). I typed sore throat runny nose back aches (without the quotes) into Google and was directed to a pharmaceutical formulation of which I was hitherto unaware: Alka-Seltzer Plus® Night-Time Cold Liqui-Gels (sic) http://www.alka-seltzer.com/plus_prods/back_night_caps.htm ! Hmm. Maybe overkill for the common cold? Guess I'm going to keep showing up in the surgery for a while longer... :-) If you want textbooks integrating towards decision support online, ISABEL is mildly interesting (http://www.isabel.org.uk/ gratis, registration required) D. -- Douglas Carnall +44 (0) 207 241 1255 +44 (0) 7900 212 881 http://carnall.org
OSHCA and LinuxWorld @ NYC 2003?
Just a thought since I received the LinuxWorld Expo and Conference catalog for the upcoming show in New York City in January 2003. Would OSHCA be interested in having a presence there in the .org pavilion? The .org area has groups from Debian Linux to local New York Linux user groups there. I am not sure of the exact details, but considering that businesses are now showing up at the expo these days in addition to the geeks ;-) it might be a nice idea. Comments and thoughts? --- Crawford The I.T.E.C. Company P.M.B. 146 368 South McCaslin Boulevard Louisville, CO 80027 USA (303) 604-2550 (voice) (866) 604-2550 (toll free) (303) 664-0036 (fax) http://www.itec-co.com
creation of data dictionary, was Re: GnuMed's unique contributionrelative to other projects, Re: report from OSHCA 2002 meeting
On Mon, 25 Nov 2002, Adrian Midgley wrote: On Monday 25 November 2002 06:00, you wrote: What compromises for expediency are present in OIO? Glad you asked :-). We have been discussing OIO's database schema over the last week or so. The main thrust of the discussion surrounds OIO's use of lots of tables, rather than few tables with lots of rows. There seemed to me to be a larger one in the storage of forms, with the lack of a data dictionary making it unfeasible to share records across multiple systems and places. Hi Adrian, Good point. The data dictionary function is provided by the OIO Library. From the concise project description at http://www.TxOutcome.Org: The major components of the OIO system are the web-accessible OIO Server and OIO Library. ... OIO Library is a metadata repository that facilitates the sharing of metadata (e.g. plug-and-play web-forms, project descriptions) between users and between OIO Servers. I do not call the OIO Library a data dictionary because data dictionary is often used to constrain / define the acceptable data elements / metadata. We are no where close to wanting to do that. We just want to catalog, organize, and share them for now. :-) But the creation of record and form is very handy - expedient. Thanks! You have found the carrot. If it is handy and expedient enough, people may be willing to use it. The side-effect is the creation of exchangeable, re-usable, adequately documented meta-data. :-) Thrusts in the UK are toward interoperability. and this requires such dictionaries to be shared and is helped by an underlying ontology. My view is that using even a tiny carrot will be much more successful than using a stick of any size. :-) What handy and expedient tools (or scary stick) are you prepared to offer in return for being constrained by UK's comprehensive and up-to-date data dictionary? Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org (hosting OIO Library #1 and OSHCA Mirror #1)
