Re: [openhealth] Openhealth mailing list
Thanks for the welcome, Bhaskar, and also the warm welcome (in every sense of the word) I've received from many others. Also, thank you for creating this list. The list software at minoru-development.com was and is broken- you took the right step to keep this incredible community conversation going. I have no intention of fixing the old list. Having two lists is confusing and creates the appearance of division where none exists. Accordingly, I'll be closing down the openhealth mailing list on the minoru site in about a week. For those who have not already joined the Yahoo list, please do so now. There is no need to unsubscribe from the minoru list, as it will be deleted. You will not be transfered to Yahoo unless you indicate that you want this by joining at http://groups.yahoo.com/group/openhealth/ . http://groups.yahoo.com/group/openhealth/ As for the trademark issue, my apologies to the group for forgetting Why I'm here. Openhealth is the name of a conversation and a community. I'll work to be more consistent about this. -Brian Bhaskar, KS wrote: First, I would like to welcome Brian back to the community. Having met him only once, and never having collaborated with him, as a newcomer to the open source healthcare community, I don't know him as well as I perhaps should. But it is always good to have an early active member in a field return to active participation. So, welcome back! I am also very encouraged by the discussion about resurrecting OSHCA. I think it was an important organization. [I do wonder, however, given the subtle changes in language over the last few years, whether FOSSHCA or FLOSSHCA might not be better names to use today...] I was the one that originally created the openhealth mailing list on Yahoogroups, and my light a candle vs. curse the darkness motivation for doing it is discussed in my post (copied below) announcing the list. In my role as moderator, I see myself as serving the wishes of the free and open source software for healthcare community. One suggestion I would make, however, is simply to leave the list at Yahoogroups. Yes, we can create our own list on our own server, but then we would be responsible for things like the list below for a server that will sit on the Internet: 1. Backups. 2. Indexing and searching. 3. Anti-virus and spam filtering. 4. Security, including keeping up to date with patches. 5. Network access, bandwidth, data center operations. I recently had an opportunity to observe the need to respond to a server that was found to have the t0rn root kit installed on it, and it was very disruptive on the lives of those who managed it. Yahoogroups does all of this for us, and the price is some advertising appended to each message (and if you opt for text messages rather than HTML messages, the advertising is at the bottom and quite innocuous). All the group moderators have to do is to approve requests to join the group. We already have several moderators from the community who are members of the group, and there is redundancy should I, or any of the other moderators, have something untoward happen to us and be unable to serve. I am also happy to accept others who would like to volunteer to serve the community as moderator. My two bits' worth: let us focus on building the new OSHCA / FOSSHCA / FLOSSHCA community, web page, portal, etc., and leave the mailing list where it is. Regards -- Bhaskar -- Background / motivation: A couple of months ago, as a result of an e-mail server consolidation following a corporate acquisition, my e-mail address changed from [EMAIL PROTECTED] to [EMAIL PROTECTED] This of course meant that I could not post to the openhealth list, since posting is restricted to members. I have tried a couple of times to subscribe with my new e-mail address, but my attempts went into the bit bucket. This has meant that although I can read posts - e-mail sent to the old address is forwarded to the new one - I cannot post and participate in discussions. Under the theory that it is better to light a candle than to curse the darkness, I have created a mailing list [EMAIL PROTECTED] Yahoo Groups (http://groups.yahoo.com) http://groups.yahoo.com%29 is a robust place for mailing lists and electronic communities, including a file repository, searchable web-accessible message archive, online chat, etc. If you would like to join, please send me e-mail at [EMAIL PROTECTED] or [EMAIL PROTECTED], and I will send you an invitation from Yahoo Groups. If you click on a link in that e-mail invitation, or reply to the e-mail, you will be subscribed to the group. Alternatively, go to http://groups.yahoo.com and search for openhealth. Ask to join the group, and I will get a message asking to approve your application to join. In an attempt to keep e-mail harvesters off the list, I have created the group requiring administrator approval to join. However, I will
Re: OSHCA Meetings
Mary Kratz had some real good comments about the value of a separate organization (eg: OSHCA) vs working groups in existing ones (eg: IMIA and AMIA) a few years ago. I'm hoping she will chime in here with an update. -Brian Horst Herb a écrit : On Mon, 20 Mar 2006 15:41, Brian Bray wrote: You should co-ordinate this with the IMIA working group on open source. http://www.chirad.info/imiaoswg/ Will do. Wasn't even aware they existed. Any point in having both OSHCA and IMIA OS WG as separate entities? Should we aim for a joint conference to discuss this further? Horst
Re: OSHCA Meetings
You should co-ordinate this with the IMIA working group on open source. http://www.chirad.info/imiaoswg/ -Brian Horst Herb a écrit : On Mon, 20 Mar 2006 03:47, Joseph Dal Molin wrote: to hold a meeting. In fact a satellite conference is preferable to imbedding a meeting in Medinfo because of the cost of registration. A low risk strategy is to find a willing host that can provide the space to meet and ideally food services that are within walking distance - a university or something like that. No worries. It is not the first conference I organize here. I was on the committee organizing two RACGP conferences (some 2000 delegates each), and together with another colleague we organized a smaller scale conference (60 delegates) ourselves too - the latter worked out very cheap and flawless. We used no sponsors deliberately - instead we negotiated with a nice resort off season to provide us all facilities for free in exchange for booking a larger number of rooms in block. We got the rooms at 60% regular rate, two large meeting rooms, audiovisual equipment, and they even threw in an afternoon tea. We could use the meeting room even at night, they gave us the key (we used it for a social gathering and watched movies on the big screen). Only thing delegates had to pay for was conference lunch and diner. Would do it the same way again Horst
List future [was: Why are you here?]
Thanks everyone for the feedback. I have a proposal that I've worked out with Molly Cheah, who is working to incorporate the Open Source Health Care Alliance (OSHCA). Joseph Dal Molin, Tim Cook, and Adrian Midgley were also involved. The proposal is to form the Openhealth list at OSHCA.ORG managed by volunteers for OSHCA. This list and the Yahoo list would be moved and closed. The OSHCA domain name and trademark would be transfered as soon as possible to facilitate this event. This proposal would realise a goal that I have had for a long time. As far as I can determine, it would meet all the concerns expressed over the last few days. Please comment on this proposal and feel free to ask any questions either on the lists or directly to Dr. Cheah or myself. -Brian
Re: The list is a valuable resource
I was able to subscribe a hotmail account, but there is a problem (see below). I'm still coming up to speed on the list history while I was away, so I'm not sure how long the problem existed. There have been a few people (maybe half a dozen) who were unable to subscribe because of incompatibility with their e-mail systems. In most cases, Dave was able to fix this manually, but I know of at least one where we had to tell the person to subscribe from another account. The problem is that no confirmation message is returned to the subscriber. I can see how this would cause a lot of confusion. Rather than wade through the tortuous documentation for the mailing list software, I will update the instructions on the openhealth site for subscribing to refer to the yahoo list. -Brian Andrew Ho a écrit : Brian, If I recall correctly, the OpenHealth list hosted on Yahoo was started because new people were unable to join the OpenHealth list hosted by Minoru. Could you please comment on whether this is still the case? Thanks, Andrew On 3/15/06, Lorie Obal [EMAIL PROTECTED] wrote: I hope the efforts to renew forums for open health discussions succeeds. The lists are an important reseource for those of us doing IS research on OS for healthcare. I've been lurking this list since I started grad school and I joined the yahoo one to keep up with the community. I'm currently working on a taxonomy of OS software and I hope to eventually get feedback from the community. -Lorie Lorie Obal [EMAIL PROTECTED] Proudly conceptualized and drafted in open source software! ---Begin Geek Code Block GMU/GB d? s: !a C LU+ P+ L++ E--- W++N++!o K- w ! M- V PS+ PE Y+ PGP++ t+ 5++X+R*tvb+++DI--!D G e++/e++h++ !r z? End Geek Code Block http://www.geekcode.com/geek.html -- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Why are you here? (was Re: Hello list)
Tim Churches a écrit : Hmmm, does Minoru plan to assert its trade mark against the Openhealth list on Yahoo (see http://groups.yahoo.com/group/openhealth/ )? I'm not expecting that I'll have to. It depends on the the other list and my decisions over the next few weeks. The way I see it, there are two possibilities for the motivations of the creators of the other list: 1) It really is a question of the technical capabilities of the list and the lack of support. In this case, the folks running the yahoo list will have no problem changing the name to avoid confusion. The two lists will either merge at some point or specialize to meet different needs of the community. The yahoo list has critical mass, so a name change is unlikely to cause its members to leave. 2) The motivation is to profit from the goodwill that Minoru has in the community on an ongoing basis. In this case, the folks running the yahoo list will resist changing the name and it will be necessary to assert the trademark to protect Minoru's interests and reputation. But, as I said, I'm not expecting this to be necessary. I believe that we can come to some understanding that is best for everyone. In any event, the needs of the community have substantially changed since the Openhealth list was created. When we started, there were just a small number of open source projects. They were duplicating each others work, the creators had never met or communicated, and the level of competition was preventing collaboration to move ahead more quickly. Thanks to you and the other members of the Openhealth list, there is much more understanding and appreciation of the merits of different approaches to solve different problems. There is also much more collaboration as projects exchange not only ideas, but modules (such as FreeB for example). Ongoing communication between projects is still important, but there are now many mechanisms and places where that happens. The question I asked in my first reponse to your note Why are you here? This is a serious question we should address to determine the future of the list and whether it still has a value in the community. The increasing number of open source healthcare projects creates a need to objective comparative reviews and critiques to help refine their work. There is also a need for greater communication and colllaboration between physicians and engineers one the one hand, and open source developers and medical informatics research on the other. Can this list help meet these needs? -- In terms of the technical capabilities of the list, the reason for the long delay in upgrading the list is that my internet service provider was not ready. I considered hosting the list on an open source product or moving it to a free service in the past, but both these options had drawbacks. It is just a fact of life that Minoru's sites are subject to attack. My ISPs report that our sites are subject to more security incidents than other sites they host, including e-commerce sites. I have hosted other lists directly, and came to the conclusion that the Openhealth list absolutely needs stronger security support than we could ensure in-house. For example, getting an e-mail saying you have more than 10,000 administrative requests. The current system, while crude and out of date, enables us to have a quiet conversation without hurculean effort. As for hosting the list on a free service, these services are not charities. I notice that the project sites for many open source projects now have advertising for directly competing proprietary products. The archive for the openhealth list suffers from the same blight. Many of the the lurkers on the openhealth list are doctors, a highly prized market segment for advertisers. Another big segment is commercial and non-profit open source enterprises who cannot and should not permit their work to used as advertising media for their competitors. Just this month, my ISP is rolling out a better mailing list service which they will support and protect, so it now possible to provide a friendlier interface without the problems mentioned above. It is up to you. Why are you here? -Brian
Re: Hello list
Right you are about Marvin. There are a million lists on the Internet and a lot of them have signs of life, but there's only one Openhealth[tm] list. Why are you here? -Brian Tim Churches a écrit : Brian Bray wrote: To quote Marvin the paranoid android (Red Dwarf) Life... don't talk to me about life. Marvin was the `droid in the late and much lamented Douglas Adams' The Hitchhiker's Guide to the Galaxy. Kryten was the `noid on Red Dwarf - sad geezers like me can read more about Kryten at http://www.sadgeezer.com/RedDwarf/kryten.htm Unfortunately, the floor show has already finished at The Restaurant at the End of the Universe (also known as openhealth-list@minoru-development.com ). However, if you engage your Infinite Improbability Drive, you may find signs of life over on openhealth@yahoogroups.com Tim C
Re: Question about OIO (was Hello list)
Andrew Ho a écrit : Completeness can never be assured without significantly restricting customizability. For example, deleting the Gender question from an existing form. In certain contexts, some limits on customizability are needed for safety reasons. Take a case worker with limited screen size in the field -- there should be no customization that eliminates or reduces to illegibility an alert field. More suble is the question of Work flow vs thought flow (I'm only guessing what that means, but it sounds cool) and whether customizability has a medical impact. Since posing the question, I came across: http://journalsonline.tandf.co.uk/(dgdmykz4q25ielnzs4drx1q1)/app/home/contribution.asp?referrer=parentbackto=issue,3,6;journal,1,27;linkingpublicationresults,1:102479,1 -Brian
How to (was Hello list)
There has never been an administrative interface. Just send a blank message with unsubscribe as a subject to either the list or [EMAIL PROTECTED] Tim Churches a écrit : I tried to unsubscribe from openhealth-list@minoru-development.com but the administrative interface to the list has been broken for several years now - or it was last time I tried it. Is it fixed now? Tim C
Re: Hello list
Thanks David, I'm in Vancouver for the moment and I'm planning to move back here, but it really depends on where my next project is. -Brian Dr. David Chan a écrit : Welcome back Brian! Sounds like you are doing a treasure hunt! Are you still based in Paris? David
Re: Hello list
To quote Marvin the paranoid android (Red Dwarf) Life... don't talk to me about life. I'm catching up on my e-mail. Only 3500 more to go! -Brian Ignacio Valdes a écrit : He LIVES! -- IV On Fri, 10 Mar 2006 09:19:09 +0100 Brian Bray [EMAIL PROTECTED] wrote: Hi all. -Brian
Question about OIO (was Hello list)
Thanks Denny and Aldric for the warm greeting. There have certainly been some interesting discussions while I was gone. (I'm just up to the end of 2003). I have a question for Andrew Ho. In the discussion about Vista/OIO complementarity, you discussed the concept that OIO let's users safely customize forms. I'm curious how this is done, particularly related to the completeness and semantics of data elements. I know I should RTFM, but a discussion might be more interesting...especially if some others with flexible systems can chime in. Thanks. -Brian
Hello list
Hi all. -Brian
Announcement (WARNING: SAD)
It is with great sadness that I announce a change in the administration of the openhealth list. Dave Scott, the list manager is no longer with us. Dave passed away last Sunday in Paris from complications of diabetes. He would have been 40 on July 29th. Dave was one of the founders and a director of Minoru Development and was a tireless crusader for open source health care. He will be missed in other communities as well. He was a director of the Vancouver Fringe Theatre Festival where he organised hundreds of volunteers. He was also active politically campaigning for changes to Canada's constitution to promote greater unity between French and English speakers. He has been a campaign manager for a Canadian minister of defense and was the editor of an award winning newletter on technical writing. His career includes management positions in government, information technology for an international engineering firm, and technical writing for Reuters. His funeral service will be held in the Toronto area in early September. An open reception will also be held at the Pere Lachaise crematorium (salle Landowski) in Paris at 9:20AM this Thursday, July 24th, for those in France wishing to celebrate his life and to say goodbye. Dave is survived by his parents Mae and Gunther ([EMAIL PROTECTED]) and his sisters Mary ([EMAIL PROTECTED]) and Heather. I thank the staff at the hospital of Versailles and the Cochin hospital in Paris for their care. For issues related to the openhealth list and the OSHCA website, the contact is now Sylvain Hellegouarch ([EMAIL PROTECTED]) and/or myself ([EMAIL PROTECTED]). -Brian -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: Germany shifts to open source
There has been a lot of activity in government sectors over the last few weeks. There is also an announcement from Taiwan and announcements of some large individual open source (Linux) sales by IBM and HP. Some links (including an alternate link for the German story) are at http://www.euspirit.org/zope/en/linkxchg/index_html Happy reading! -Brian
Re: I met a guy... HL-7
Bill Lober wrote: I met a guy at a CDC conference this week who told me he knew of an open-source effort to build HL-7 message-handling software. Anyone have any leads? Thanks in advance, Bill Go to http://www.euspirit.org/ and type hl7 into the search field. There are several projects specific to HL7. Also, some of the larger projects have HL7 links or components. -Brian -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: new subject
Other CorbaMed (now OMG HDTF) implementations: Circare: http://openhealth.com/circare/ contains a partial PIDS implementation in C++ PICNIC http://picnic.euspirit.org/ is producing PIDS and COAS components in Java. -Brian Thomas Beale wrote: Bruce Slater, MD wrote: Thanks for all the information from Thomas Beale, Tim Churches, Adrian Midgley and Falbal. Concerning EMPI: Do people use CORBAmed? I am sure it has to be as complex as it seems to be generalizable across platforms, but it creates too much of a barrier for me right now to understand all that stuff. I know of: - LANL's implementations - these appear to be current and under working development, so Dave Forslund is probably the best person to ask about status - 2AB has implementations of TQS and PIDS and I think RAD at least - the Brazilian group at InCor in Sao Paulo have implementations of RAD, PIDS (I think) and maybe COAS - not sure what the GCPR project built, but Ken Rubin (on this list) is the person to ask there My hope is that our openEHR work can be used to update COAS and the order management specification, since these are somwhat out of date now. - thomas beale -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: The Register - Gnome to be based on .NET - de Icaza
I think the significant event is that Microsoft is working to become a leader in the open source movement. They are financially supporting Openstate (Perl) and providing technical assistance to Ximian (MONO / GNOME). They have their favourite licences (BSD) and their supporters. It does not hurt windows or Microsoft to have free software running on the windows platform. Even things which are Windows clones (or .net clones, or DCOM clones, or MS-word clones, ...) are not so bad as long as the Microsoft versions are the definitive and high end originals that lead the market and set the standard for others to follow. There are really two visions for the relationship between open source and proprietary products in the marketplace: 1) Open source follows the tail lights of proprietary software. Innovation is first seen in proprietary products, which eventually become standardized commodities in open source. Proprietary vendors must recupe their investment in the limited period before they are overtaken by open source imitators. With the right licences, open source software can be used as a base for proprietary add-ons. 2) Public research regains the initiative from private research. Substantial innovation would come from widely funded and/or publicly funded research projects that are then commercialised by vendors. Similar to research in other fields, as the body of past results (ie: open source code) gets larger and more sophisticated it becomes more and more difficult and specialised to contribute to what's already there. Commercial operations would specialise in the composition, configuration, customisation, and support of standardised open source components for their clients or their own use. I think both things will happen to some extent and it will take quite a few years before one model will come to dominate the other. A lot depends on the battles over intellectual property rights legislation and the funding levels for open source informatics researchers. -Brian Le Dimanche 3 Février 2002 01:01, Tim Churches a écrit : On the [EMAIL PROTECTED] list, David Guest wrote, wrt The Register - Gnome to be based on .NET - de Icaza: Times change. http://www.theregister.co.uk/content/4/23919.html I am reminded of a (possibly apocryphal) saying which is reputedly popular amongst neo-Marxist revolutionaries who suddenly find themseves in power (e.g. the Sandinistas in Nicaragua): The only thing worse than ruthlessly being exploited by multinational corporations is not ruthlessly being exploited by multinational corporations. ... Tim C
Re: Link Exchange. Was: Economic theories
The plan is to make recent links available in RDF format for exchange with web portals. -Brian Jon Edwards a écrit : Hi Brian, Is there any way your list of links can be pulled onto ther sites? Perhaps an RSS feed, or something like dmoz.org does? Hmmm maybe someone should start a dmoz category for open-source healthcare software, then we could all use that one central resource to put links on our sites? :-) Cheers, Jon Jon Edwards Pricom Ltd www.pricom.co.uk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 08 December 2001 11:56 To: [EMAIL PROTECTED] Subject: Link Exchange. Was: Economic theories The Spirit site http://www.euspirit.org/ has a link exchange service to more permanently record links to interesting open source health care resources. The service includes keeping a short description of the link and categorizing the link. You can view recently submitted links, search the descriptions, or browse by category. -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: UK Wanless report: response from OSHCA needed
Bart Koppers a écrit : 2. a Sourceforge-like repository of locally developed healthcare applications; The Spirit project has expressed plans to build this. I guess we're not informed of the current status, or development might be low/slow. The status of the Spirit Forge was discussed on this list a couple weeks ago. The short answer is It's in testing. We have proposed to the NHS to install a repository of locally developed healthcare applications and we would really like to help them with this. The issue is that this was not part of their policy agenda, so there was no mandate to do it. This is where Douglas' feedback is important because it can affect the policy level. Yes, and perhaps a list of NHS organisations/projects using open-source, and willing to answer simple questions about How we did it? Maybe some case-studies? As far as I can remember, it was discussed on the OSHCA-meeting that the Spirit project could (or should..?) provide some guidance in this. Also , read http://www.euspirit.org/documents/brochure-amia.pdf The projects we are aware of are in the Spirit project index. We are a partner with one of the NHS trusts in the PICNIC project, where open source components will be piloted within the NHS. ... 3. Maybe some guidance for businesses who might want to open-source their existing products? I'd love to see one of the smaller GP-systems suppliers open-source their software as a way of competing against the dominance of the few big companies. This is still a very important issue, and IMHO still underestimated here: business models. Now economy has a small dip, people are more aware that every business (open source products or not) needs a good basis for survival. Just an idea and (hopefully) compentence alone will not sufice. I thought -again- it was one of the aims of the Spirit project to provide some insights in the various business models. Am I the only one unaware of any developments in that area by Minuro/Conecta/Sistema (=project partners of Spirit)? Brian, could you shed your light on this? Sure, I would be happy to. Start with the Spirit Industry Model at http://www.euspirit.org/library/brianbray_1_en.pdf We also provide 47 links to articles on the Internet related to Open Source Business Models at: http://www.euspirit.org/zope/en/linkxchg/showall?link=BBusiness%20case We disseminate the Spirit material, including discussion of business models at many conferences and events. Events so far this month have been the 6th World Congress on the Internet in Medicine in Italy (Nov 29-Dec2) and the Information Society Technologies for Health (Eurolatis) conference in Cuba (This week). All the material (slides, posters, papers, etc.) from dissemination events is available in Deliverable D8 at: http://www.euspirit.org/documents/deliv-d8.pdf http://www.euspirit.org/documents/appendices-d8.zip (warning 11 MB) The current document covers the first six months of the project. An update will be available next month covering the period from July to December. The real issues with the business models is working out how to apply them to a specific situation. Models like using open source software to promote hardware or book sales really don't apply unless you are already in the hardware or book business! So, we offer specific and customized advice to research organisations, health care organisations, and vendors worldwide by giving customized seminars. The common slides are in Deliverable D8. More information can be found at: http://www.openhealth.com/en/products.html More specific to your situation, I have visited the Netherlands twice this year to present Spirit/Business models and I'm already scheduled for another presentation next year. The Spirit team would be happy to meet with other Dutch projects and groups. -Brian -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: Link Exchange. Was: Economic theories
Before we all go for another round of my project list is better than your project list, let me point the thread was about the Spirit Link Exchange service, not the Spirit software index. This is a separate service that holds links to interesting articles, rather than links to software development projects. Most of the links are to press articles, papers, or sites containing a variety of resources of interest to the open source health care community. Also, it's really not fair to the other members of the Spirit consortium to call it Brian's site. While, I am the editor of some of the data, the software for the index component was primarily developed by Conecta and the European Commission was the primary funding source. The software index and link exchange do not favour European projects or links, it really depends on who decides to enter something. Since the subject of project lists has come up, there are a variety of reasons for differences in the projects listed in different sources and the information that is kept: 1) Because Minoru is producing a commercial CD-ROM of open source software, we need to be very particular about licensing details and compliance with the open source definition. All of the lists contain projects that are not open source, however. 2) The Spirit software index is multilingual, so we need project descriptions that are not going to change frequently. 3) We don't present subjective evaluations of the projects, just statistics and links to information maintained by the project itself. 4) We have a commercial focus so the software index is designed to link to vendor information and promotional material. 5) We encourage projects to highlight peer reviewed articles in the scientific literature that evaluate the clinical and cost impacts of their approach as well as articles about reference sites. 6) The Spirit software index is designed to serve as a primary or secondary download point for software source code and to hold source code from orphaned projects. The subtleties are that the lists serve different needs and audiences. -Brian Ignacio Valdes a écrit : Jon Edwards wrote: Hi Brian, Is there any way your list of links can be pulled onto ther sites? Perhaps an RSS feed, or something like dmoz.org does? Hmmm maybe someone should start a dmoz category for open-source healthcare software, then we could all use that one central resource to put links on our sites? :-) Cheers, Jon Jon Edwards Pricom Ltd www.pricom.co.uk Shameless plug for LMN warning Don't know about Brian's site, but Linux Medical News has most of the same stuff, and has an rss feed as well that many sites already pick up. E-mail me off the list and we can set it up. The difference between Brian's and mine is that Brian's is more Europe-centric although LMN does cover International as well. On the other hand, LMN doesn't have a Europe bureau and Brian has a much better view of the Eiffel tower than I do here in Houston. Of course, we think it is just a Texas sized oil rig. /Shameless plug for LMN warning -- -- Ignacio Valdes, Editor: Linux Medical News http://www.linuxmednews.com 'Revolutionizing Medical Education and Practice' -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
An inclusive consensus building process for OSHCA
At the OSHCA 2001 meeting in London, there was one important motion made at the session on OSHCA business. The motion followed a long discussion about the role, organisation and goals of OSHCA. After some discussion Adrian Midgley proposed that OSHCA establish and publish a list of members and that otherwise the organisation continue to run in the fashion it had in the previous year. This motion was seconded by Joseph Dal Molin. Brian Bray then proposed an ammendment that membership be based on a simple agreement with the OSHCA charter and the membership list be used as a voting list to decide the democratic future of OSHCA. This motion passed by acclamation. This motion has resulted in the creation of the [EMAIL PROTECTED] mailing list as a temporary membership system and considerable innovation and excitement around OSHCA's role and member services. I think this activity is very healthy and is a strong sign of the growing maturity of OSHCA as an organisation independent of and growing beyond its founders. Many new participants in the open source health care community are learning about OSHCA and the various community resources and projects. Some of the old debates about the purpose of OSHCA and its role in society are being revisited in the light of changing circumstances and the OSHCA experience over the last two years. There are at least two or three groups working on proposals for the incorporation or constitution of OSHCA as a democratic organisation. Virtually all of these proposals will involve some modification to the OSHCA charter. As a minimum, the charter needs to be ammended to include a process for its ammendment over time and to tie it to the proposed democratic legal entity. With or without a charter ammendment, it is clear that their is at least as much variation in the expectations that people have for OSHCA now as there was during its creation. Some proposals will surely include expanding OSHCA much beyond an annual meeting. I am sending this message in an attempt to make this decision making process inclusive of all interested parties and a way of consensus building so that OSHCA continues to build and grow. I propose that: 1) We need to allow reasonable time for people to develop their proposals without feeling that this is a race, or that decision can be made while they are on vacation. Specifically, I suggest that we ask for concrete proposals from those interested to be drafted by March 31 for e-mail discussion in the summer, for in person discussion at the OSHCA 2002 meeting, with an electronic vote shortly thereafter. 2) No change in OSHCA in the meantime. Particularly, that we not create either implicitly or explicitly a partnership. We should continue to accept and use the term OSHCA supporter. We should continue to support the independence of the OSHCA supporters from each other. No OSHCA supporter has ever agreed to be represented by or be bound by the decisions of other supporters and this should not change now. 3) The focus of the discussion should be on the [EMAIL PROTECTED] mailing list which requires acceptance of the OSHCA charter to join. The list moderators (Joseph Dal Molin and Ignacio Valdes) need to ensure that diverse opinions can be heard without bullying by members with different views. 4) That we undertake a membership drive between now and OSHCA 2002 to include as many people as possible in this decision. 5) That if the proposals before the voters are numerous or extremely divergent, that we use a process of elimination to ensure that as much consensus as possible is built. 6) That the voters list be public (name and city), but that voting be anonymous. I feel that these steps would go a long way to building OSHCA and avoiding rifts in the organisation. Participation at this stage of OSHCA's development will translate into long term, committed, and well educated support. Exclusion of anyone or any point of view would lead to OSHCA achieving less than its full potential. If you are interested in participating in this process, please join the [EMAIL PROTECTED] list. Instructions are on the OSHCA web site http://www.oshca.org/ Thanks, -Brian -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: Automated Form Tool
Smith, Todd a écrit : I noticed this software from a post over at Hardhats in reference to printing, http://www.scansoft.com/ Is there a problem, with just scanning in to the respective applications, FreePM and OIO all of the forms that might be found in a typical physician's office? Obviously, there are physician practices that are represented here and on openhealth. Just have one of them send paper examples of every form that they have and then use something like Scansoft to create electronic forms from them. Collecting samples (scans) of medical records from around the world was one of the projects for the openhealth-list I suggested over a year ago ( http://www.mail-archive.com/openhealth-list@minoru-development.com/msg00844.html ). This was suggested a means of getting more information flowing between medical practitioners and developers in open source health care. The Spirit site (www.euspirit.org) will shortly have an Introduction to open source medical informatics group authored online resource (Wiki) where this information could be hosted. Bud Bruegger is the editor of this resource. I have spoken with Bud an he would be happy to host this information and the entire Spirit team can use our spirit contacts to seek out this information from European sources. We could accept paper documents for scanning or anyone can upload scanned documents since the resource is an open forum. A desciption of this service from the Spirit portal plan http://www.euspirit.org/documents/deliv-d3.pdf follows: -- Needs, Objectives, and Benefits The open source health care community is quite specialised and difficult to approach for new potential participants who are missing certain key concepts. In particular, participation on a development project requires background knowledge in these areas: Health care Health care management Computing science Available open source systems Many potential participants come from closely related communities such as the general open source programming community, the medical profession, or the proprietary health care informatics community. These potential participants need an introduction to the concept areas that they are not yet familiar with in order to join the community. Also, participants in roles outside of development have an occasional need to look up specific technical terms. Description The Introduction to Open Source Health Care Informatics knowledge base is designed to deliver basic information for newcomers. The community itself, especially newcomers, will build this resource. The technology framework is a Wiki collaborative authoring system that lets community members create, edit, and refine topic entries. The topic entries form a searchable and expandable web site. More information on this tool is described later in this document. The site will be seeded with basic topics written by the Spirit team. This service is experimental and depends on community involvement for the ongoing editing and monitoring of the content. Security is by basic e-mail confirmation of identity. It is easy to find newly created or edited topics either from the site or by e-mail notification. Multilingual Features Although topics can be created in any language, this will primarily be an English resource. If sufficient interest is shown, alternate language forums may be created at a later date. Cost and Availability This is a free community service. -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Spirit news
The Spirit portal plan and the Spirit dissemination plan are now available online at http://www.euspirit.org/documents/deliv-d3.pdf and http://www.euspirit.org/documents/deliv-d4.pdf respectively. The portal plan describes the services to be made available at the Spirit site over the next several months. The dissemination plan describes how we hope to get the word out about open source health care to a broader audience. The portal plan also contains a general model for understanding and guiding the growth of open source health care -- the evidence based software model. I would appreciate hearing your comments and questions. I'm particularly interested in whether you agree that the evidence based model for open source health care development matches your expectations. Thanks. -Brian -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: Open Source Software in Public Administrations
Ignacio Valdes a crit : Just curious, how many came from random people from outside of openhealth? I got your comments, Minoru and openhealth list coverage to a large number of people, not only on my site, http://www.linuxmednews.com/linuxmednews/986236502/index_html but some biggie news outlets as well. I'm interested to know how much activity that kind of thing generates for third parties. All of the inquiries were from Openhealth list members. It did cause some traffic to our web site: Article % of all offsite referrals (April 1-12) Newsforge 0.43% LinuxMedNews0.2% LinuxNews 0.2% You will have a lot more statistical information on usage patterns of our community starting in July. Every three months the Spirit site will be publishing a report on the size and activity in open source health care as measured by Spirit, Openhealth, and OSHCA site statistics. -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: Fw: GT.M V4.2-001 released
"Smith, Todd" a crit : Hello Jim, As has been pointed out, Vista still has a ways to go for some large-scale applications, like Patient Accounting. However, if such a system could be built, then completely Vista run hospitals can become a successful reality. Yes, I know that VA hospitals are nearly completely built on Vista, but I thinking private hospitals. Todd Smith [EMAIL PROTECTED] In some countries outside the U.S., the patient accounting needs tend to be similar to the V.A. case (ie: one payor). Thinking globally may lead to earlier success here. -Brian -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: help please
"John S. Gage" a crit : Brian, Doesn't this sound like the beginning of our low-cost hospital information system fantasy? You were not being facetious when you said it was your favorite. John "First Dutch Hospital on Linux" http://lwn.net/2000/1019/a/hiscom.php3 I'm very serious. For the benefit of North American readers, you should be aware that many countries in Europe are already far ahead of your wildest dreams in the adoption of open source. For many parts of the public service here, it's not a matter of "if", or even a matter of "when", but a matter of "how". Health care is closely tied to the public sector in most parts of Europe. Some concrete examples for our Spirit travels: Dave heard a minister of the economy for one of the smaller member states talk at length about the advantages of Zope for public administrations. Some specific administrations have entirely switched to open source and are now giving talks on how to do it. The CIO of a hospital information systems vendor (integration and outsourcing) that Joseph and I spoke with indicated that virtually all of her customers (about 20 hospitals) were planning the transition to Linux in two years time. She was worried about how whe could bring her staff up to speed. My feeling is that a lot of health care system vendors are starting to plan their transition to open source -- either proprietary products on Linux or releasing their product line under open source licences. Some concrete examples of "early adopters" on this list are Nautilus/Odyssee and GT.M. One of the big tasks of the Spirit project is to visit vendors, care delivery organizations and policy makers to educate them about open source. Part of the transition is releasing their existing code under open source licences. We offer a seminar from http://openhealth.com/minoru/testmdc/en/products.html for this. It is our goal to increase the base of open source health care software by this means. You can help by pointing us at the best opportunities (or pointing them to us). We will be making all the briefing materials public as soon the Spirit site goes live, so that you can use the same information in your presentations if you want. -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: Pfizer, IBM, and Microsoft to Offer Rx for Health Care
Andrew Ho a crit : ... Are greater reliability and lower cost sufficient to sell/disseminate products in the medical software market? Perhaps not. If we examine the evolution of computing in other "more technologically" advanced fields, it is clear that "functional"-bloat is essential to market penetration. There is an important but small subset of the market where open source is an absolutely essential feature -- informatics training and research. When these systems have been deployed in research and academic settings for a few years and have a track record in the literature, then it is not just a matter of greater reliability and lower cost, but also patient outcomes. Even this is not sufficient because many proprietary health care systems are able to point to studies and reports from users about their effectiveness. Commercial exploitation is also needed to turn software into customer solutions. -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
[Fwd: Free / open source software actions in European RTD - 18 May 2001 - Brussels]
FYI. -Brian Original Message Objet: "Free / open source software actions in European RTD - 18 May 2001 - Brussels" Date: Mon, 2 Apr 2001 10:47:22 +0200 De: [EMAIL PROTECTED] [Apologies if you received multiple copies of this message - Please send us a message asking us to delete your name from our mailing list if you do not wish to receive information from our unit] Dear Ms., Dear Sir, A special information event will be held in Brussels on Friday 18 May 2001. Developers of innovative free / open source software, as well as companies and organisations serving these developments, will obtain up-to-date information on the European RTD funding opportunities. The event will serve as a platform for building contacts with other interested parties. An invited speech by David Faure will treat "KDE as a development platform". Thank you for booking 18 May now in your agenda, and returning the registration form as soon as possible if you plan to attend. Refer to: http://www.cordis.lu/ist/ka4/tesss/prog.htm for full information on the programme of this event, and for registration details. Best regards, Tania Devroede, on behalf of Philippe Aigrain Head of Sector "Software Technologies" European Commission DG INFSO/E2 Office N105 3/54 [EMAIL PROTECTED] Postal address: rue de la Loi 200, B-1049 Brussels, Belgium Office address: avenue des Nerviens 105, B-1040 Brussels Secretary: Tania Devroede Phone: +32.2.295.0411 [EMAIL PROTECTED] Phone (direct): +32.2.296.0365 Fax: +32.2.296.7018 http://www.cordis.lu/ist/ka4/tesss/
Re: Not really, Brian.
Ignacio Valdes a crit : [SNIP] Thanks for the forthright post. I apologise for spelling your name incorrectly. We are adding a link to the spirit homepage http://www.euspirit.org to link to the LinuxMedNews project list. It was an oversight not to include it, but the list was only created yesterday, so you were not missing for long. The Spirit site officially opens in June, although some services will be made available before then. The current page is just a simple page containing basic project information. The "Links" button will not have the same function as the site evolves. The Spirit partners are: Minoru (FR), Conecta (IT) and Sistema (IT). The recent call for partners by our firm was for another potential project unrelated to Spirit. There is no funding guaranteed for this project. The Spirit plans will be published on the Spirit website within a couple of weeks. We see the Spirit website as a complementary effort to LinuxMedNews because the readership is different and the services are different. The Spirit portal is targeted at three very specific target groups. I'll attempt a U.S. translation of who these groups are: 1) Health care informatics innovators: Research scientists in healthcare computing and interested vendors and individuals. 2) Informatics policy makers: The folks who write the HIPPA and FDA guidelines. 3) Regional care network management: Executives and managers of managed care organizations. Correct me if I'm wrong, but the LinuxMedNews site seems aimed at a young technical audience with an interest in health care technology and open source. Also, there is no budget or plans in the Spirit project to write news articles about our community and this is the primary activity of LinuxMedNews. There is a customizable portal page that will show headlines from selected news feeds. I hope to include LinuxMedNews among the choices, so this should generate traffic to your site. We will generate our own news feeds related to new software releases in the index, and other events on the site, but these are automated services. I hope this helps explain things. -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: Not really, Brian.
Wayne Wilson a crit : Brian Bray wrote: The Spirit portal is targeted at three very specific target groups. I'll attempt a U.S. translation of who these groups are: 1) Health care informatics innovators: Research scientists in healthcare computing and interested vendors and individuals. 2) Informatics policy makers: The folks who write the HIPPA and FDA guidelines. 3) Regional care network management: Executives and managers of managed care organizations. I will anxiously await your marketing plan for getting to these folks. Don't take the "U.S. translation" too seriously. The initial targets are in Europe and most of our marketing effort is there. I hope others can use the Spirit backgound materials to start the process in the U.S. The portal itself should work internationaly and be a focal point for international co-operation. What's encouraging is that I know is that they are already starting to arrive. This list get's more of them every day. It's a problem because most leave within a week. This forum is not well adapted to their needs -- we need Spirit now. -Brian -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
DocScope (was VB - Middleware)
Horst Herb a crit : I meant that Doctors - and Doctoresses ;-) - program many little tools (drawing curves, giving risk evaluation using Framingham equations, and so on). In France, a contest was recently organised to elect the best of it ! But as these tools are autonomous, and then launched outside patient record software, they need re-enterering lots of datas to work. The straitforward effect of that is that they remain gadgets. If people took time to developp it, it is because they needed that function. That is the reason why I think a good medical record must be able to act as a Middleware ; it is a genuine *plus* for open source approach. I am a strong believer in small autonomous *pipeable* tools - that is what makes UNIXes rock. With XML etc. we have the possibility of formalizing a piping protocol. That way, all the language discussion is futile, software becomes more robust (it is much easier to test debug small tools than large monolithic applications). However, this is difficult to achieve in a GUI world. Horst Have a look at the DocScope vision statement http://openhealth.com/docscope/ Many of the ideas discussed recently on this list are also contained in that document from one year ago. Standardized XML records, Document/arch types, scripting to make it so that a broader group can "program" the application. The technical approach is to adapt web browsers (either HTML controls or Mozilla itself) to be the front end, thus solving the "GUI world" problem that Horst Identifies. We have been invited by a funding agency to submit a specific proposal to evaluate it's clinical effectiveness. We are currently looking for partners with the following characteristics: 1) Research organizations in primary care informatics preferably with an attached care delivery (ie: practice) organization. 2) Research organizations in evidence based medecine and informatics evaluation. 3) Regional care networks with a primary care mission component. 4) Wireless / handheld and portable medical device manufacturers and/or service providers 5) Home care organizations 6) Individuals and companies with ENV13606 standards experience. Please respond to [EMAIL PROTECTED] or [EMAIL PROTECTED] if you are interested. -Brian -- Brian Bray Minoru Development Corporation; Minoru Development SARL The home of Openhealth(tm): http://www.openhealth.com 3, rue du Colonel Moll, 75017 Paris France +33.6.8750.2465
Re: EMR Data Definition
[EMAIL PROTECTED] a écrit : Hello, I am developing an EMR system and would like to know if there is a data definition for an EMR (preferably a relational schema) that has been defined or is recommended by one of the standards organizations (e.g. HL7, ANSI). Anyone know of any and if so, do you have any pointers to where they might be on the web? Thanks in advance, Don A lot of newer projects are looking at object oriented definitions of EMRs instead of directly relational ones. This work can be made more specific and concrete by using OO models to create relational tables or XML schemas, DTDs, archetypes, etc. OO modeling is better able to capture the complexity of EMR data. The major work worldwide is the HL7 RIM Reference Implementation Model (RIM) which is being used as the basis for standards outside of HL7 as well. They expect to use the model to inform message definition in version 3 of the HL7 interface standard. There were other simpler models developed at the NHS (search for the NHS information model) and for the Good European Health Record (GEHR). Such models describe the health care system in general and can be used to guide the development of EMR systems as well as messaging systems and cross system interfaces. If you want something more concrete, you can look at the XML work of the OIO project, FreePM, DocScope, the CEN TC.251 standard (search for preENV13606) and HL7 Patient Record Architecture (PRA) standard. There is also the API focussed work of the GEHR project, LANL Telemed, and the CorbaMed standards. The two projects specifically focussed on general purpose open source EMR components are GEHR and DocScope. GEHR is focussed on API access to the EMR, while DocScope is based on using XML tools to access files in preENV13606 format. References to related open source projects can be found at http://openhealth.com/en/healthlinks.html Links to the standards organizations are: http://www.hl7.org http://www.omg.org/homepages/corbamed/ http://www.centc251.org -Brian
Re: Mining, was: A Proposal
Horst Herb a écrit : [SNIP] Sorry, this might be a dumb question, but how would you actually data mine such a chaotically growing structure salad at a public health level? This is ultimately what we want to achieve, isn't it? Gather information on a broad base to facilitate evidence based medicine, isn't it? I fail to see how that can be achieved without centrally defined data structures and term glossaries. Horst This is the concept that systems like OIO, Circare, and DocScope (and now FreePM), as well as to some extent GEHR are based on. The basic code reads meta descriptions of the information along with display/input/processing rules specific to the information types defined. New categories of information can be added dynamically. From the point of view of collecting information from disparate sources (eg: Circare) this is really ideal because the information can be kept close to it's original form. From the point of view of research into health care informatics (eg: OIO), it permits easy changes to the information collected and processed. You are correct to be concerned about the difficulties mining this information for analysis. This was a major issue in Circare, for example. However, healthcare is local. The flexibility in these systems enables them to adapt to local requirements, but also it's important to realize that these systems all have a relatively fixed collection of information types when installed at a site for a specific purpose. The mining of the information can use the same tools as the systems themselves (eg: CorbaScript, Python, XSLT, and the tools used to transfer and validate XML data). A specific study at a specific site will need to customize their mining tools to the available data. I.E. the mining tools will themselves reference the same meta-information. In the end, these tools would format the information for conventional databases and/or statistical analysis packages. At least this was the theory for Circare! It really remains to be seen what the advantages and disadvantages are in practice and what tools are most useful for this use case. When you talk about scaling these tools to a national level, even a national system has a finite number of data types. Furthermore, a particular research analysis is not going to need to use all the data and all data types. Also, its quite clear that the schemas/archetypes/DTDs used in a particular context are not going to be developed completely independently. Similarities between type definitions can be used to reduce the complexity of the mining task (for example, many data types may use the same coding scheme internally that can be mined with a single XSLT script) Going back to your original comments, Another way of looking at this is that these systems *do* have, in practice, a "centrally defined data structure and term glossary.", it's just not hard coded into the application code and it's defined locally. -Brian
An open source virus
This virus works on the honor system. Please delete all the files on your hard disk, then forward this message to everyone you know. Thank you for your cooperation.
Standards work
If you are interested in participating in a protential open source development project related to CEN.TC251 and/or ISO.TC215, please let me know by private e-mail at [EMAIL PROTECTED] Responses accepted in English, French, or Italian. -Brian
Re: Digest version of openhealth-list?
Ignacio Valdes wrote: Is there a digest version of this list available? If not can one be created? Thanks -- IV A digest version will be available soon. Our Internet service provider has just finished testing a new list service which we will be switching to shortly. It has a digests (both MIME and regular) as well as web based sign up and many other features. I'm going to wait until after the OSHCA inaugural meeting before updating the list software. That way, other changes to the list (if any) can happen at the same time. -Brian
OSHCA charter comments
If I were to sum up my vision of OSHCA in one line it would be: A forum to get together and create open source health care projects. I see it's main function is to provide a meeting place for users and developers to form consortia on a large enough scale to launch open source initiatives with enough "critical mass" to dominate their markets. Tactically, I think that the best way for OSHCA to accomplish such a mission would be through in-person meetings and a directory of interested parties. I see the group as primarily focussed on business and not technical issues. I don't see the group as a whole promoting any particular project, standard, or technology. One characteristic of successful open source projects is the users of the technology and its developers are one and the same. On an individual scale, it's possible to just start a project with the hope that others will join in to the extent required to succeed. At the scale of an organization, such as a hospital or a health network, it's unthinkable to start a project without enough resources to complete it. This chicken and egg problem is a barrier to wider adoption of the open source approach. OSHCA can solve this by providing a forum where folks interested in a particular application area can get together to pool resources and distribute risk. Imagine our progress if every organization buying proprietary software contributed just 5% of it's costs to projects to develop open source alternatives. Such a policy would lead to massive cost reductions over the long term. On the developer side, open source code is typically written by individuals, small companies, or research groups. Here too, pooling resources is one way to tackle larger projects and compete effectively against entrenched proprietary alternatives. In this view, OSHCA is *not*: - an architecture - a project index - the openhealth list - a development project - a standards body - a web site -Brian
Re: HL7 RIM and GEHR archetypes
"Alvin B. Marcelo" wrote: ... 3. Circare: having trouble getting all the prerequisites... It would be good to have more specifics here (off-line). Many of the prerequisites are available from a subdirectory of the distribution location. There may be value in having one central resource where all the projects and future projects can download the needed components to develop and run open source applications for health I think this is called the Internet ;-) Seriously, I don't think we need to have *one* site with everything on it. Not very many people are going to be installing everything. TK-Family practice and Freemed are for physician's offices, while Circare and Telemed are more for larger organizations. Generally people are going to be installing just one of these. Mainly, however, it is very easy and not expensive to find somewhere to host a web site. Each team can chose an arrangement that they are comfortable with and that gives them control over their own destiny. There is no need for our community to take on the extra effort co-ordinating and hosting everything in one place. Source Forge, just as an example, provides a pretty complete service for free. All of us have an interest in making our products as easy to install as possible, so specific comments on install issues would, I'm sure, be welcomed by any team. Even more welcome would be someone volunteering to produce packages specific to the installation procedures for different distributions. For example: RPM packages for RedHat or install scripts for windows. alvin
Re: HL7 RIM and GEHR archetypes
Brian Bray wrote: ... Seriously, I don't think we need to have *one* site with everything on it. Not very many people are going to be installing everything. TK-Family practice and Freemed are for physician's offices, while Circare and Telemed are more for larger organizations. Generally people are going to be installing just one of these. Mainly, however, it is very easy and not expensive to find somewhere to host a web site. Each team can chose an arrangement that they are comfortable with and that gives them control over their own destiny. There is no need for our community to take on the extra effort co-ordinating and hosting everything in one place. Source Forge, just as an example, provides a pretty complete service for free. I'm following up my own mail here, but there was one thing I left out. I think the idea of creating a "demo CD" of all the health care related applications as suggested by Jeff B would be a good use of someone's time and effort. Just to recap Jeff's idea, there are bootable demo CDs of Linux, that could be modified to include all the apps pre-installed. I got a demo of this (just the Linux part) at a freemed event here in France and it is pretty slick. One can just put the CD into any modern PC and in less than three minutes, Linux is running with a GUI desktop. The hard drive is not changed when booting this way. -Brian
Re: Patient control
"John S. Gage" wrote: It definitely will be different every time. I think the essential question is: model in XML or UML? What are your ideas about the advisability of each (knowing in advance that you are modeling in Eiffel)? The advantage of XML is that it is closely related to the concept of a document, which as Brian points out is very near and dear to medicine. XML is not really a modelling language. So UML is the still king here. XML is one way to manipulate data objects defined in UML. So I say full speed ahead with the modeling efforts that are already underway. -Brian
Re: Patient control
"John S. Gage" wrote: David Forslund wrote: I would recommend using tools where they are designed. That means using UML and XML where appropriate. XML is a representation of data not a design tool. UML can be expressed in XML (using XMI) if you like. It seems to me that the very meta-data aspect of XML that is used to tell the XML parser what the XML document is all about is, in fact, a modeling function. Models, if there are more than one of them, have to be able to describe themselves (I think), and there are always going to be a myriad of models in medicine. The entire literature on practice variations tends to support this. So how do you handle multiple models? XML looks good for simple modeling that can describe itself and can easily be translated into an object database. Or am I completely off the mark? John You are not wrong, but the modelling parts of XML are primarily for machine consumption. UML models are specifically designed for communication between people. -Brian
Re: HCFA forms
amarcelo wrote: If HCFA is .gov then FOIA should apply right? Has this been addressed by opensource.org? I remember a previous thread about open source being different from public domain. Basically, the difference is in the license (ie, the gov't cannot give out a license therefore it is technically _not_ open source per se but the code should be available (?) (more of a question than a statement)... alvin Code in the public domain fits the definition of "Open Source". Very little open source software is in the public domain. Most is copyright material released under a licence. There are some pretty good reasons to do this -- public domain material can be subsequently copyrighted by someone else if it's modified even a little. -Brian
Re: Patient control
"Robert R. Hausam" wrote: As a physician, I agree with Thomas's comments. See additional comments below. At 11:46 AM 1/24/2000 +1000, you wrote: "John S. Gage" wrote: Brian Bray wrote: The more I think about EMR, the more I think of a document for each patient. No database or middleware needed ;-) Well, except for: - physician access (as noted by John) - administrative access - data filtering, querying and searching - security, encryption - visual filtering - multimedia - automated processing of populations of records I might also add: - real-time clinical decision support (typically rule-based systems - generally requires structured data and use of a controlled vocabulary) - recalls and reminders (probably subsumed in a couple of the categories above) There are probably others, but these lists likely cover most of the major categories. The little winking smiley face ";-)" (turn your head to the left 90 degrees) usually indicates a joke or in this case, a tongue in cheek comment. Even if you conceive of medical records as documents, you are going to want to index them (ie: use a database) and you if you are accessing them from a distance, you will want to be able to request selected portions only (ie: have some middleware). Also, no EMR exists in isolation. Doctors want to get paid, so they need to codify things and handle financial transactions. There is no "magic bullet" that's going to eliminate databases and middleware from our lives. I'm surprised, however, at the reaction to the document concept. This is not new -- my understanding is that there are are number of groups (including one in HL7) that have been working on SGML document type definitions for medical information for years now. Consider the same reasoning in an accounting context. There are even stronger arguments that all accounting data should be kept in databases. But accountants have a document format -- the speadsheet. It's easily transmittable. There are a lot of tools for dealing with speadsheets. It's conceptually simple. It's flexible enough for an extremely wide range of accounting needs. You would be foolish to try and store the accounts receivable for a major corporation in a speadsheet, but you would be equally foolish to write a custom database application to do a small budget. Each tool has it's use. When I say documents, I'm not talking about a simple text file ! I'm really thinking about a structured XML document meeting a standard for medical records. This type of document can contain codified values, pictures, special processing code, etc. Really, it's a way of encoding object instances in a portable and durable format. What things would it be good at? 1) Transmission. 2) Long term storage. The format can be stable over a very long time frame. The format can be read manually with a simple text editor. Some information can be extracted from partial records. It is self documenting to some extent and contains or links to it's formal definition. 3) Interface to legacy systems. The format is trivial to generate and relatively simple to input. There is widely available source code for doing this. 4) Universal viewing. There are an increasing number of tools that could view records in this format -- Browsers and major word processors are among this number. 5) Good match to the problem domain. I can see how someone in an accountants office could believe that the whole world could be modelled with tables containing rows and columns, but how can you look at a medical chart like this? XML is a natural fit with the object models now being developed in health care. 6) Widespread tools. In addition to viewing, there are an increasing number of tools to do other things with XML documents. This includes a query language, transformation tools, format conversions, large scale storage and management tools, etc. 7) Standarized APIs. DOM is the standard. According to earlier mail on this list, Corbamed COAS is related. 8) Robustness, transparency, and conceptual simplicy. Documents are easy to understand. There is a direct correspondence to the paper world. 9) Simple load distribution and easy to understand security. What about the supposed drawbacks? I'll concede that some of them are valid if the documents are literally stored as separate files in a directory. But even then it really depends on the number of records you've got and what you are trying to accomplish. A small family practice is probably doable this way. Physician access: I suggest that a file you can read with Micosoft Word or Netscape is way more accessible to physicians than an object or relational database. A system that could produce such records gives physicians a lot more real control over their data. Regardless of how the documents are stored, I suggest that the "document per patient" model is how most phy
Re: Example of CORBA
Greg Kreis wrote: Brian Bray wrote: I really agree with this concern. Corba has a huge learning curve and some of it's component standards are much better than others (I curse the C++ bindings daily). If I was a CORBA vendor, this would be my biggest concern. HTML caught the computer world by surprise and upset the apple cart for many a client/server vendor. Could CORBA be in a similar predicament? I DO NOT want to start a flame war. Not at all. But I am wondering if some interoperability standard (perhaps using XML) is going to sneak up on the CORBA/DCOM/EJB world. Describing this competitor, I'd say it probably won't be as sophisticated as them, BUT it will be a lot simpler for legacy systems to implement. I think is one way to look at the HL7 / Corbamed debate. HL7 is going to XML defined transactions based on transmitting extensible data objects in an easy to process public format while CorbaMed is putting fairly abstract active objects into large servers and communicating by exchanging data structures. The thing that will make or break Corba though is its implementations and the way they interact with higher level standards such as CorbaMed. To give a specific example, the CorbaMed PIDS standard, like a lot of other recent standards, provides a set of links to other components in it's primary interface. This means that you can go from a PIDS object to an associated Naming service, Trading service, or Notification service. You return a simple NIL value to indicate that you don't support this type of service or provide a link. Sounds simple? Corba IDL has no ability to partially define a type, so the interface for these other services must be included in the IDL for the PIDS interface. These interfaces themselves provide links to other components. When using a statically typed language, this means that the generated header files for virtually every Corba standard is included for every PIDS source file. On my system this means over 50,000 lines of header files before a single line of PIDS server code is processed by the compiler. This makes no difference to the end product, but slows development. I don't have a Notification service, so I return a NIL value. The automatically generated code from the IDL compiler doesn't know that I'm only sending a NIL, so it's ready to send anything. It bulks up my executable with 615K of automatically generated object code to send that one NIL. Is this a problem with the PIDS IDL? The Corba IDL language. The C++ binding standard. My ORB implementation? My development tools? It could be fixed at any of these levels, but it's really a consequence of how they all work together. My choices are: 0) Accept that 615K is OK to send a NIL(after all, it's just *virtual* memory) 1) Edit the automatically generated header and source files manually 2) Abandon the standard C++ binding (other open source projects have done this) 3) Implement an "almost PIDS" interface 4) Create my own "short" idl definition of the Notification Service. I.E. Fake a partial definition. What do the Corba folks on the list recommend? Can we come up with a design that is above DCOM, CORBA or EJB so we can remain neutral enough to easily migrate to a different strategy? The obvious problem with this approach is it adds one more layer of complexity and performance drain to the onion. The great advantage, in my eyes, is being able to rest easy that the EMR would be better prepared to withstand a Standards earthquake. While Corba doesn't have to be large and slow, some of the implementations are. This benchmark shows there can be a WORLD of difference in the speed. http://www.omex.ch/CorbaTB/corbatb.htm The more I think about EMR, the more I think of a document for each patient. No database or middleware needed ;-) -Brian
Re: Example of CORBA
I really agree with this concern. Corba has a huge learning curve and some of it's component standards are much better than others (I curse the C++ bindings daily). While Corba doesn't have to be large and slow, some of the implementations are. If you want a self demo and to learn a little from something pretty concrete, I highly recommend CorbaScript http://corbaweb.lifl.fr/CorbaScript/ It's an interpretted language that can access and define Corba objects. The samples that come with the interpreter show how you can "do corba" with "one line of code". -Brian Greg Kreis wrote: Does anyone know of a concise example of a CORBA based system that is described on the net? I'd like to get a look at a couple of designs to get different ideas on how folks decided to arrange their model's classes to be served up via CORBA. What sorts of CORBA success stories are out there? I went to a presentation of ObjectSpace's Voyager ORB Tues. evening. They talked about how their product was able to bridge/adapt to DCOM, CORBA and EJB. They also pointed out, for instance, that to access a CORBA object might take about 10 lines of code where they require one. One thing that struck me about the presentation was how intellectually interesting it is to talk about all these layers of technology, yet how it might not pan out in the end due to practical matters. Running lots of services/servers all linked together over a wide variety of connections (LAN, Inernet, etc.) and getting them all to come together in a user's desktop app reliably and quickly is a daunting task. Perhaps we are at the stage of distributed systems where we were with LANs in the 1980s. Lots of promise, but lots to do before everyone naturally assumes it is there and working. I hope this does not take us too far off the main theme here, but I personally don't have work experience in using or running distributed object systems and so I don't know the reality that is hidden behind the media's articles.
Re: HCFA forms
Would it make sense to do a freedom of information act inquiry to release the source code for this tool? Especially if it looks like a number of open source projects are going to have to duplicate some of it's functionality. -Brian Mary Kratz wrote: Ah, the perfect application of Open Source for US vendors and providers alike. HCFA mandates do not add any value to a healthcare software application (say a finance app), but ALL US vendors must embed this logic in their systems, or no provider will purchase the product offering. Trouble is, every vendor interprets the HCFA requirements slightly differently. The result is that the data going to HCFA is then hard to interpret/use. Bob Mayes at HCFA had the vision to build a toolset to address these issues. MedQuest is the name of the toolset, and HCFA makes it freely available off the HCFA web site at http://www.hcfa.gov/medquest/medq1.htm. Bob's recent efforts focus on metadata. One quickly realizes the benefits of metadata in a complex data set, such as HCFA is responsible for. I believe the metadata definitions are currently being incorporated into the MedQuest offerings, but Bob would know better than I. If you *really* want the HCFA forms, you can ask HCFA for a copy. I did this a few year back, when I took on a position as EDI Coordinator. HCFA sent me a package about 15 inches of paper in depth...at least a month's worth of reading! Very ugly!! Hope this helps. I'm sure Bob would like feedback on MedQuest. -Mary At 01:00 PM 1/19/00 -0500, Alvin B. Marcelo wrote: Question from an outsider: Which HCFA forms are providers required to submit in the US? Is there a way of connecting a HCFA electronic form to a database so that appropriate fields are extracted from the database, placed on the form, and then printed pdf-like _using open source tools_? I know this can be done with Adobe Acrobat but is there an open source counterpart? Thanks. alvin -- Alvin B. Marcelo, M.D. National Library of Medicine, B1N30 Office of High Performance Computing and Communications Bethesda, Maryland 20894 Voice: 301-435-3278 Fax:301-402-4080 eFax:603-452-3657 Work: [EMAIL PROTECTED][EMAIL PROTECTED] Home: [EMAIL PROTECTED] PGP keyID: 0x6E9941D1 PGP server: http://www.keyserver.net
Re: AMIA 2000
Thanks for bringing up the Open Source Practice Management Summit we held last September. It's purpose was to get all the groups working in this area together to exchange information on what they are doing and find things "they can steal from each other". I.E. Good ideas, source code, ... One of the topics of discussion was what forum is the right one for continuing and expanding this effort. Although the discussion was short, we decided that AMIA was the right forum. In fact, we walked away with the goal of getting an open source track in next years AMIA. The main reason was that information exchange with the rest of the medical informatics community would be "a good thing". This is two way -- getting the open source message out there *and* learning from the work of others so that our open source products can be better. Of course if we are all in the same place at the same time, we'll learn from each other and have a good time as well. Going with an Open Source conference, such as O'Reilly, was also discussed, but we seemed to have less in common with that group than with AMIA. Also, we were aware of the upcoming AMIA agenda that included several open source or near open source topics. The O'Reilly conference tracks are by product (ie: Linux, Apache, Perl, Python, ...) not by application area. The option of hosting our own conference was considered premature. I think we all felt that it was important to focus our efforts on a single annual event. We can't really expect most volunteers to do more than this. However, picking a european conference to descend on was also felt to be a good idea so we could cover more of the world. I'd certainly like to participate. I think we need more than a panel and I think it would be *very good* to have presentations from all the major open source product groups out there. A one day "track" feels about right to me. Because of the volunteer nature of many of these projects, it may be necessary to have some financial support for getting the key folks there and registered -- particularly if the conference is expensive. I think we should approach groups that stand to profit if we succeed (Red Hat, VA Research, key OMG members, O'Reilly, Governments agencies, etc.) to see what can be arranged. We should see if the AMIA can discount their fees -- we are after all bringing free software. If the fees are prohibitive, we could consider having our own conference at around the same time and place so that we have both an internal forum at low cost and the ability to interact with AMIA members. -Brian "Daniel L. Johnson, MD" wrote: Well, actually Minoru, the host of this list, sponsored the first (annual?) open-source medical software conference in September, 1999. Perhaps this tradition could be continued. Joe and Brian, what is your view of this? Nevertheless, AMIA does offer a huge forum at which we stand a chance of engaging the interest and participation of others who do not yet know The One True Way (our way, of course), and so I would be sorry to abandon AMIA entirely despite its financially painful ticket price. Danl Johnson
Re: Circare description
Alvin Marcelo wrote: Thanks Brian. That was a concise but clear presentation of Circare. I would like to bother you for more by asking you to give me (or us) a step by step approach on how to build a Circare system in let's say, a small primary care practice. It may be on your website, but it would be nice to hear it from you. Or you can refer us directly to the webpage. The circare web page is at: http://www.minoru-development.com/circare The installation instructions are in a file called INSTALL in the source code directory. Circare is very much a work in progress (very little real functionality to date) and is not easy to install at this time. I would be happy to provide e-mail assistance to anyone brave enough to install it in it's present state. There are plans to write an implementation guide that would help installation. The first version is targetted at health care networks, not at individual physician practices. The components would be very useful for a physician practice (PIDS is very widely applicable), but they would need to be packaged specifically for this application. A few questions too: 1. You are using the CORBAmed model. There have been concerns ( in past posts) raised about its capability to completely represent medical information (unlike the abstract GEHR and HL7). How do you respond to this? CorbaMed is incomplete. Taking a abstract model, such as the HL7 one or others, and elaborating specific interfaces is a large but extremely valuable goal. I'm sure that the CorbaMed group would welcome proposals from the open source community for new CorbaMed interfaces. These interfaces do not *need* to be standardized to be useful for open source development. 2. I am concerned with the ff statement (maybe because of lack of in-depth knowledge of CORBA technology): medical information. It's architecture is based on the CorbaMed PIDS standard. The PIDS standard is primarily for patient identification but it allows access to of an arbitrary number of attributes of arbitrary types. Is arbitrariness a virtue or a curse? I had thought that the less arbitrariness there is, the better. Am I missing the context of "arbitrary" here? A standard needs to be flexible to be widely applicable. The fact of the matter is that I'm using this flexibility to make PIDS do something for which it was not primarily intended. The actual implementation is not "arbitrary". Circare uses the flexibility in the standard to define it's own specific attribute types. Implementing a system with too much flexibility is a waste of effort. A standard without enough flexibility, is not widely applicable. Total arbitraryness is bad. Corba, along with XML, and SQL allow the definition of "arbitrary" things (objects, documents, tables) and provide meta information (UML, doc types, data dictionary) to be able to work with them. Please help. alvin
[Fwd: V3DT seeking your advice on value of a reference implementation.]
I have forwarded this message from the HL7 lists to this one because of it's general interest to this group. -Brian Hi again, in this message I am soliciting your opinion on a very concrete question, I am especially asking you as an implementor/vendor of HL7 standards. (1) What do you think is would be the value of a reference implementation of the HL7 version 3 data type (V3DT) specification? (2) What programming language would you like to see such a reference implementation? (3) Would you use the reference implementation in your own software as you prepare for HL7 version 3? The background to those questions is that I recognize the HL7 version 3 data type specification is pretty abstract and at the same time surfaces a lot of issues that an implementation needs to take care of. Thus people may be afraid that this stuff is not implementable or to complex for them. Some might fear that if HL7 version 3 is going down that path it may become a perfect standard, but may not be a *useful* standard. While I can understand people having those fears, I do believe that the version 3 data types will make things easier in the long run. Especially as we struggle towards more interoperability: our goal is to share *meaning* not just characters in data fields, and precise definition of meaning is oftentimes not trivial. This is especially important for clinical data. I personally would like to help HL7 implementers appreciate the V3DT specification and to receive its benefits without too many hassles. I would also like to present a stronger proof of concept for the entire V3DT approach. A reference implementation (V3DTREF) in the form of open-source code would be an ideal way to do this. However, this requires a considerable committment to resource allocations to this project. This does not make sense if there are no "customers" for it. I know that some vendors are reluctant to use third-party code since this may turn out to be a maintenance trap. Also the problem is that not everyone uses the same platform for development. Since V3DTREF would be a software component for tight integration into HL7 systems, it needs to be very close to the software development environment that people intend to use for their own HL7 v3 projects. Data types need to be right under the hood, not just loosely connected from outside by long wires. A Java Bean, a CORBA component or an ActiveX control may already be too far away. My reference platform of choice for this project would certainly be Java, since it is the most hassle-free answer to multi-platform support. However, Java does have downsides, mainly in the area of performance and failure to integrate smoothly in multi-language projects. I'd be interested to hear whether people consider Java as the platform for their HL7 v3 developments. This project is not yet going, it is just my personal idea and I don't even know if I can spend any resources on this. I appreciate any of your thoughts to add to the little "brain-storm" here. Also, I would appreciate to know whether you would consider helping in such a project, either through commitment of time or through funding. sincerely, -Gunther Gunther Schadow, MD -- http://aurora.rg.iupui.edu Regenstrief Institute for Health Care 1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960 [EMAIL PROTECTED] -- #include usual/disclaimer - To unsubscribe from this list, send a message to [EMAIL PROTECTED] with "unsubscribe cq" (without the quotes) in the message body.
Re: V3DT seeking your advice on value of a reference implementation.
This project is not yet going, it is just my personal idea and I don't even know if I can spend any resources on this. I appreciate any of your thoughts to add to the little "brain-storm" here. Also, I would appreciate to know whether you would consider helping in such a project, either through commitment of time or through funding. I will need to create some HL7 components for some open source projects that are coming up in the next year or so. This means that I can commit some time to such a project and that there is some possibility of funding down the road (although nothing specific yet). As for potential customers, I think that there are really three types: 1) Traditional vendors using the reference implementation as a code base to start their own efforts. 2) Open source vendors embedding the reference implementation as part of larger open source projects. 3) Vendors and users of all sorts using the reference implementation as an interoperability testing tool and design model. My own ideas on this topic have centered on the third customer type because it is the most general. A parsing library, while useful, is not as interesting as a parsing library as part of a generally useful toolkit. I have been dreaming about a kind of web based HL7 monitor that could take a file or communication channel of HL7 messages and convert them to HTML for browser display. Perhaps it could also generate test messages and diagnostics for protocol and profile violations. Other tools in the kit could include an "anonymizer" that replaces patient and physician identifiers, HL7 version / format converters, filters that can do uniform substitutions on HL7 fields, or extractors that build tables of observed field values. For my purposes, C++ is the right technology for this. I think that the most useful product for VB/Corba/Scripting users would be to have an activeX/Corba interface so that they could drive a parsing/communication engine from their preferred environment. Java is another choice for this, but I would worry about performance issues. There are also problems calling into Java code from some other programming environments as you point out, although getting Corba/COM interfaces seems to be easier than C++. The most portable choice is probably still "C", since nearly any modern environment can call into "C" code. My only problem is a personal one -- C seems so restrictive after C++. -Brian
Open source health care links
I have placed a few links to open source health care resources on: http://www.minoru-development.com/en/healthlinks.html Comments and new entries welcome. -Brian
