From nsh at pop.jaring.my Wed May 16 14:17:55 2007 From: nsh at pop.jaring.my (Nah Soo Hoe) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] test Message-ID: <464AA213.3010505@pop.jaring.my> test From nsh at pop.jaring.my Wed May 16 14:33:14 2007 From: nsh at pop.jaring.my (Nah Soo Hoe) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] test2 pls ignore Message-ID: <464AA5AA.8000703@pop.jaring.my> From drcheah at pc.jaring.my Wed May 16 14:33:40 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: [participants] OSHCA inter-operability list] Message-ID: <464AA5C4.9060204@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Lee Seldon Subject: [participants] OSHCA inter-operability list Date: Tue, 15 May 2007 13:49:21 +1000 Size: 4689 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/d17739c2/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:34:30 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA5F6.2090204@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: "Alvin Marcelo" Subject: Re: [participants] OSHCA inter-operability list Date: Tue, 15 May 2007 13:09:49 +0800 Size: 10319 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/d5ea1d81/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:35:00 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA614.6040804@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Molly Cheah Subject: Re: [participants] OSHCA inter-operability list Date: Tue, 15 May 2007 13:36:24 +0800 Size: 7659 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/4f0e6ebe/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:35:24 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA62C.2060204@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: "Jason Tan Boon Teck" Subject: Re: [participants] OSHCA inter-operability list Date: Tue, 15 May 2007 13:55:16 +0800 Size: 5971 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/f1996d82/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:35:42 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA63E.9030908@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Ravindra De Silva Subject: Re: [participants] OSHCA inter-operability list Date: Tue, 15 May 2007 11:31:27 +0530 Size: 3742 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/0fc532f3/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:36:07 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA657.90607@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Molly Cheah Subject: Re: [participants] OSHCA inter-operability list Date: Tue, 15 May 2007 14:25:07 +0800 Size: 5140 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/7f57215d/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:36:25 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA669.4080909@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Ravindra De Silva Subject: Re: [participants] OSHCA inter-operability list Date: Tue, 15 May 2007 12:39:28 +0530 Size: 5709 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/1851992d/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:37:23 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA6A3.3080802@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Jel Coward Subject: Re: [participants] OSHCA inter-operability list Date: Tue, 15 May 2007 09:24:12 -0700 Size: 4420 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/d761b1f0/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:37:41 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA6B5.9080803@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Jel Coward Subject: Re: [participants] OSHCA inter-operability list Date: Tue, 15 May 2007 09:28:12 -0700 Size: 5195 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/2ba580cf/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:38:07 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA6CF.1020801@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: "Boh Heong Yap" Subject: Re(2): [participants] OSHCA inter-operability list Date: Wed, 16 May 2007 01:29:00 +0800 Size: 7770 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/3d5f9190/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:38:25 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA6E1.8000306@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: "Alvin Marcelo" Subject: Re: Re(2): [participants] OSHCA inter-operability list Date: Wed, 16 May 2007 09:29:13 +0800 Size: 20169 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/6934adb1/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:38:45 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: [participants] Re: OSHCA inter-operability list] Message-ID: <464AA6F5.5000506@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Lee Seldon Subject: [participants] Re: OSHCA inter-operability list Date: Wed, 16 May 2007 13:16:01 +1000 Size: 4415 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/6d0a9ba4/OSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:38:58 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464AA702.6010808@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: "Jai Ganesh" Subject: Re: Re(2): [participants] OSHCA inter-operability list Date: Wed, 16 May 2007 09:28:09 +0530 Size: 7309 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/2094fc09/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:39:10 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] Re: OSHCA inter-operability list] Message-ID: <464AA70E.5010303@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Molly Cheah Subject: Re: [participants] Re: OSHCA inter-operability list Date: Wed, 16 May 2007 12:14:52 +0800 Size: 6888 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/19d07265/OSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:39:30 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] Re: OSHCA inter-operability list] Message-ID: <464AA722.20505@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Tim Cook Subject: Re: [participants] Re: OSHCA inter-operability list Date: Wed, 16 May 2007 00:47:44 -0400 Size: 8269 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/4bf499cc/OSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 14:40:16 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] Re: OSHCA inter-operability list] Message-ID: <464AA750.6000104@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: "Boh Heong Yap" Subject: Re(2): [participants] Re: OSHCA inter-operability list Date: Wed, 16 May 2007 14:23:48 +0800 Size: 8506 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/1bbec7f0/OSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 15:14:52 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] Re: OSHCA inter-operability list] Message-ID: <464AAF6C.7060304@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: "Klaus D Veil" Subject: RE: [participants] Re: OSHCA inter-operability list Date: Wed, 16 May 2007 17:07:23 +1000 Size: 6074 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/fae02c86/OSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Wed May 16 15:22:01 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Re: [participants] Re: OSHCA inter-operability list In-Reply-To: <006001c79788$e00c2ff0$09648255@acerkv> References: <006001c79788$e00c2ff0$09648255@acerkv> Message-ID: <464AB119.6080302@pc.jaring.my> Hi Klaus, We're transitioning to the new list FOSS_health@oshca.org You're welcomed to subscribe to the new list and participate in the discussions as OSHCA is be initiating test beds for developing and testing interoperability with real FOSS applications. Molly Klaus D Veil wrote: >Molly, > >I really missed catching up with all conference participants in KL, but am >very happy to assist in any way I can with the OSHCA interoperability >effort. > >Klaus > >_______________________________________ > >Klaus D Veil > >Research Fellow, University of Ballarat, Australia >Chair, Standards Australia IT014-06-03 >Chair, HL7 Australia >Director, HL7 Board >HL7.org (USA) Certified V2.4 & V2.5 Specialist >Principal, HL7 Systems & Services >Mob: +61 412 746 457 Skype ID: "KlausDVeil" >Fax: +61 2 9475 0303 E-mail: Klaus@Veil.net.au > > > HL7 Australia >___________________________________________ >PO Box 3289, WESTON CREEK 2611, Australia >Phone: +61 412 746 457 Fax: +61 2 9475 0685 >E-mail: Chair@HL7.org.au Web: www.HL7.org.au >____________________________________________ > > > > >-----Original Message----- >From: participants-bounces@oshca.org [mailto:participants-bounces@oshca.org] >On Behalf Of Molly Cheah >Sent: Wednesday, 16 May 2007 14:15 >To: OSHCA Conference participants >Subject: Re: [participants] Re: OSHCA inter-operability list > >It is wonderful to see the enthusiasm here. While I'm trying to absorb all >these discussions and at the same time attend to my own urgent urgent >outstanding work, I can't respond as fast as Lee's expectation of his >preference for a dedicated list on interoperability. I fear such dedicated >lists will fragment the OSHCA community which I'm trying to co-ordinate >during the conference to be followed by post-conference activities. While >the pros and cons are being thought through by OSHCA management, the >participants list does not deter further discussions here. > >It will be difficult for OSHCA to subsequently coordinate the discussions >and decisions made on third party lists and on other different platforms >which I don't think are interoperable. > >I've asked Soo Hoe who had been creating and organising the mailing lists >for OSHCA to look into this. I've just talked to him on the phone and he >will post on this matter later today. In the meantime please be patient and >continue with the discussions here and we'll move the relevant archives to >where it should be. > >There are several outstanding matters that a few of us are still addressing. >One example is the temporary wiki (with content) sitting in the box that was >set up during the conference for participants to input. >It's still in the black box and I'm sure there are inputs on >interoperability there. My headache is: how do I move that information to >the OSHCA web-portal.... I really don't want to burden participants with >management matters. As one participant said to me on my juggling with >available funds, "what has that to do with me?" That's part of my learning >process on community and community development. > >Rgds, >Molly > >Lee Seldon wrote: > > > >>Alvin Boh et al. >>This interoperability discussion seems to be progressing faster than I >>expected, but >>1) I would REALLY prefer to pursue it in a dedicated list, so as not >>to clutter up everybody's email. An OSHCA list would be most >>appropriate, but otherwise maybe a Yahoo group or even Skype, or we >>could each make our own list (of one another). >>2) The point-to-point interface would be quickest, but I myself would >>only be interested in a generic approach involving all applications, >>so as to establish interoperability not only here and now, but also >>for the future. >>3) It should not be necessary (or useful) for everybody to study HL7. >>As long as at least one person (project manager?) knows enough, he/she >>can answer questions. >>4) http://www.ahml.com.au/ is the best place to test your message >>compliance. >>Lee >>_______________________________________________ >>participants mailing list >>participants@oshca.org >>http://mailman.oshca.org/mailman/listinfo.cgi/participants >> >> >> >> > >_______________________________________________ >participants mailing list >participants@oshca.org >http://mailman.oshca.org/mailman/listinfo.cgi/participants > >_______________________________________________ >participants mailing list >participants@oshca.org >http://mailman.oshca.org/mailman/listinfo.cgi/participants > > > > > From tanboonteck at gmail.com Wed May 16 15:29:53 2007 From: tanboonteck at gmail.com (Jason Tan Boon Teck) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Fwd: [participants] Re: OSHCA inter-operability list In-Reply-To: References: <464A7771.90501@alum.mit.edu> <005601c79788$db8f0c40$09648255@acerkv> Message-ID: ---------- Forwarded message ---------- From: Jason Tan Boon Teck Date: May 16, 2007 3:21 PM Subject: Re: [participants] Re: OSHCA inter-operability list To: OSHCA Conference participants Cc: alvin.marcelo@telehealth.ph Q: Is HL7 V3 a replacement for V2.x? Is there an upgrade path? A: ... Early adopters of V3 are typically in a "green field" situation with no installed HL7 systems. Some implementations have been of a academic/research nature. So far there is no upgrade path from existing V2.x messages to V3 messages. This looks scary. [shudders] jason On 5/16/07, Klaus D Veil wrote: > Also, if some of you want a simple HL7 FAQ (or provide this to a colleague), > go to: www.HL7.com.au/FAQ.htm > > Klaus > > > HL7 Australia > ___________________________________________ > PO Box 3289, WESTON CREEK 2611, Australia > Phone: +61 412 746 457 Fax: +61 2 9475 0685 > E-mail: Chair@HL7.org.au Web: www.HL7.org.au > ____________________________________________ > > > > > > > -----Original Message----- > From: participants-bounces@oshca.org [mailto:participants-bounces@oshca.org] > On Behalf Of Lee Seldon > Sent: Wednesday, 16 May 2007 13:16 > To: alvin.marcelo@telehealth.ph; OSHCA Conference participants > Subject: [participants] Re: OSHCA inter-operability list > > Alvin Boh et al. > This interoperability discussion seems to be progressing faster than I > expected, but > 1) I would REALLY prefer to pursue it in a dedicated list, so as not to > clutter up everybody's email. An OSHCA list would be most appropriate, but > otherwise maybe a Yahoo group or even Skype, or we could each make our own > list (of one another). > 2) The point-to-point interface would be quickest, but I myself would only > be interested in a generic approach involving all applications, so as to > establish interoperability not only here and now, but also for the future. > 3) It should not be necessary (or useful) for everybody to study HL7. As > long as at least one person (project manager?) knows enough, he/she can > answer questions. > 4) http://www.ahml.com.au/ is the best place to test your message > compliance. > Lee > _______________________________________________ > participants mailing list > participants@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/participants > > _______________________________________________ > participants mailing list > participants@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/participants > -- Jason Tan Boon Teck -- Jason Tan Boon Teck From drcheah at pc.jaring.my Wed May 16 15:47:54 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Re: [participants] Re: OSHCA inter-operability list In-Reply-To: <464AB4C6.1040603@alum.mit.edu> References: <005601c79788$db8f0c40$09648255@acerkv> <464AB4C6.1040603@alum.mit.edu> Message-ID: <464AB72A.9090108@pc.jaring.my> Lee, Can you subscribe to the new list FOSS_health@oshca.org and take the discussions there? Thanks. We're transitioning.... Molly Lee Seldon wrote: > And HL7 Australia has a very useful list of existing tools > http://www.hl7.org.au//HL7-Tools.htm > >> Also, if some of you want a simple HL7 FAQ (or provide this to a >> colleague), >> go to: www.HL7.com.au/FAQ.htm >> >> Klaus > > >> Alvin Boh et al. >> This interoperability discussion seems to be progressing faster than I >> expected, but >> 1) I would REALLY prefer to pursue it in a dedicated list, so as not to >> clutter up everybody's email. An OSHCA list would be most >> appropriate, but >> otherwise maybe a Yahoo group or even Skype, or we could each make >> our own >> list (of one another). >> 2) The point-to-point interface would be quickest, but I myself would >> only >> be interested in a generic approach involving all applications, so as to >> establish interoperability not only here and now, but also for the >> future. >> 3) It should not be necessary (or useful) for everybody to study HL7. As >> long as at least one person (project manager?) knows enough, he/she can >> answer questions. >> 4) http://www.ahml.com.au/ is the best place to test your message >> compliance. >> Lee > > > _______________________________________________ > participants mailing list > participants@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/participants > > From tom.jones at tolvenhealth.com Thu May 17 07:49:01 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Another interoperability resource Message-ID: You can also look at www.wikihit.org where people are collaborating on interoperable clinical data defintitions. Tom Jones, MD Chief Medical Officer, Tolven Sonoma, California 707 695 5712 (mobile) 707 939 7845 (office) www.tolven.org www.tolvenhealth.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/89459071/attachment.html From lseldon at alum.mit.edu Thu May 17 08:32:57 2007 From: lseldon at alum.mit.edu (Lee Seldon) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] VistA and HL7 In-Reply-To: References: Message-ID: <464BA2B9.4020204@alum.mit.edu> Here is a document describing (the original) VistA's involvement with HL7 messaging. http://www.va.gov/vdl/application.asp?appid=65 Called "Generic HL7 Interface Handbook" I assume that this would also apply to World VistA, but it would be good to get confirmation from there. Lee PS: A student of mine in the USA writes "Since the funding for my-health-e-vet was canned by congress (my-health-e-vet was to replace VistA) facilities are now looking to purchase vendor systems to run in conjunction with Vista / CPRS to extract the stored data within VistA modules but to provide the end user with a friendlier interface. I guess what I am saying is that VistA / CPRS is great for administrative / financial management and serves the purpose for outpatient / doctor office longitudinal electronic health record but fails for the documentation / data intense acute inpatient applications." From tom.jones at tolvenhealth.com Thu May 17 08:38:29 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] VistA and HL7 In-Reply-To: <464BA2B9.4020204@alum.mit.edu> Message-ID: That is an interesting take on things. Everything I had ever heard about my-health-e-vet did not lead me to believe that it had aspirations to replace VistA. I rather thought that it was supposed to provide a patient view into VistA so that it could be represented as the PHR for veterans (that, of course, was a questionable view of PHR's) Tom -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of Lee Seldon Sent: Wednesday, May 16, 2007 5:33 PM To: foss_health@oshca.org Subject: [FOSS_health] VistA and HL7 Here is a document describing (the original) VistA's involvement with HL7 messaging. http://www.va.gov/vdl/application.asp?appid=65 Called "Generic HL7 Interface Handbook" I assume that this would also apply to World VistA, but it would be good to get confirmation from there. Lee PS: A student of mine in the USA writes "Since the funding for my-health-e-vet was canned by congress (my-health-e-vet was to replace VistA) facilities are now looking to purchase vendor systems to run in conjunction with Vista / CPRS to extract the stored data within VistA modules but to provide the end user with a friendlier interface. I guess what I am saying is that VistA / CPRS is great for administrative / financial management and serves the purpose for outpatient / doctor office longitudinal electronic health record but fails for the documentation / data intense acute inpatient applications." _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From tw_cook at comcast.net Thu May 17 09:26:19 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] VistA and HL7 In-Reply-To: <1179362390.7031.70.camel@oship> References: <1179362390.7031.70.camel@oship> Message-ID: <1179365179.7031.74.camel@oship> On Wed, 2007-05-16 at 17:38 -0700, Tom Jones wrote: > That is an interesting take on things. Everything I had ever heard about > my-health-e-vet did not lead me to believe that it had aspirations to > replace VistA. I rather thought that it was supposed to provide a patient > view into VistA so that it could be represented as the PHR for veterans > (that, of course, was a questionable view of PHR's) That is exactly what myHealth-e-Vet is/was. Also, as far as I know the VistA interface was and is loved by many end-users. So I'm a bit confused by the writing from Lee's student. Maybe I don't understand the context it was written in? -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070517/41d54ee8/attachment.pgp From drcheah at pc.jaring.my Thu May 17 09:53:53 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464BB5B1.9000802@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: Nandalal Gunaratne Subject: Re: [participants] OSHCA inter-operability list Date: Wed, 16 May 2007 18:22:43 -0700 (PDT) Size: 6840 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070517/7388ed32/participantsOSHCAinter-operabilitylist.mht From drcheah at pc.jaring.my Thu May 17 10:12:59 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Re: [participants] OSHCA inter-operability list In-Reply-To: <294404.24341.qm@web58709.mail.re1.yahoo.com> References: <294404.24341.qm@web58709.mail.re1.yahoo.com> Message-ID: <464BBA2B.7060602@pc.jaring.my> Nandalal, I have forwarded your email to the FOSS_health@oshca.org list. Please continue discussions on interoperability on that list. Appreciate your co-operation on this so that it will be easier for OSHCA to monitor and report on these activities later. I would like to request those who wanted to participate in the interoperability test beds to subscribe to the FOSS_health@oshca.org list asap. I will be re-submitting OSHCA's proposal for the Collaborative Grant to IOSN+3 next week and I will rely on the discussions on that list to add content and names of interested parties as partners to that grant proposal. I will also outline what are needed in the grant proposal particularly related to deliverables for the grant proposal. In other words, FOSS_health@oshca.org will be our working environment for that grant proposal with inputs from those who want to be part of that proposal. Thank you. Rgds, Molly Nandalal Gunaratne wrote: >Since Sahana is going to get integrated into all of >these areas of healthcare, it is a case for >pre-deployment of Sahana in hospitals. Your third >scenario maybe the reason. If Sahana is used by >hospitals to keep stock items/employees and contact >details/expertise/bed strength/service areas it could >be valuable in case of a disaster. > >There will also be people who are familiar with >Sahana, which is a bonus. > >Nanda >--- Ravindra De Silva wrote: > > > >>>Yes, Ravi. We've already thought of a scenario >>> >>> >>where MrA was washed up >> >> >>>(alive) during a tsunami and sent to a clinic >>> >>> >>using PrimaCare, where he >> >> >>>was found to have developed complications and he >>> >>> >>had to be referred to >> >> >>>the hospital using >>> >>> >>?Hospital-OS/VistAOutreach/MyVistA/VistA VOE for >> >> >>>investigation and further treatment. Naturally, >>> >>> >>the Health Dept using >> >> >>>CHITS was also interested in him because he's a TB >>> >>> >>patient absconded >> >> >>>from treatment and he's still in an infectious >>> >>> >>state. In the meantime, >> >> >>>his wife couldn't find him and went to an NGO >>> >>> >>using SAHANA... to ask for >> >> >>>help as their house was washed away too. >>> >>> >>excellent scenario! >>very well highlights how several systems maintain >>their own records of >>the same person. the challenge is provide one portal >>with info from all >>these records, so one can find TB data, victim data, >>patient record,ect >>with in a single click. >> >> >> >>>Hmmm... can we have more scenarios for our >>> >>> >>write-up for funding? >> >>yes ,lets brainstorm , here are three potential >>scenarios from me, >>though not as good as the one you mentioned. >> >> >>1. The hospital already has records of the patients >>through >>VISTA/OSCAR/OpenMRS/CHITS/HospitalOS,ect with their >>location info. Once >>the disaster occurs happen in location A, SAHANA can >>be fed with these >>data as potential missing persons. For an >>organization who makes >>sure ,every missing person is accounted for , this >>gives them a list to >>start with. >> >>2. when ever a person record is entered into the >>health care >>application , we can assume that the patient is now >>in the hospital. now >>if this health care application provides some thing >>like an RSS feed, >>SAHANA installation can subscribe to that , and >>update the relevant >>missing persons as found in the hospital(by >>comparing name,id no,ect). >> >>3. SAHANA has a request management system and tons >>of medicines pour in >>at the event of a disaster to match the overwhelming >>need. since these >>data is already captured in SAHANA, may be the >>health care application >>can use it get an idea of the resources and demand >>the health care >>workers needs to cater. >> >> >>and of course there is a lot of scope for pandemic >>integration for >>SAHANA, for which i hope to collaborate with >>NetEpi,ect. >> >>cheers >>ravindra >> >> >>_______________________________________________ >>participants mailing list >>participants@oshca.org >> >> >> >http://mailman.oshca.org/mailman/listinfo.cgi/participants > > > > > > >____________________________________________________________________________________Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. >http://answers.yahoo.com/dir/?link=list&sid=396545469 >_______________________________________________ >participants mailing list >participants@oshca.org >http://mailman.oshca.org/mailman/listinfo.cgi/participants > > > > From drcheah at pc.jaring.my Thu May 17 10:18:13 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA inter-operability list] Message-ID: <464BBB65.5090506@pc.jaring.my> Nandalal, I've forwarded another post of yours on interoperability to the FOSS_health@oshca.org list. You have probably not received my e-mail yet. Please move future discussions on interoperability to the other list . Thank you for your co-operation to streamline OSHCA activities. Rgds, Molly -------------- next part -------------- An embedded message was scrubbed... From: Nandalal Gunaratne Subject: Re: Re(2): [participants] OSHCA inter-operability list Date: Wed, 16 May 2007 18:56:03 -0700 (PDT) Size: 10269 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070517/a6103229/participantsOSHCAinter-operabilitylist.mht From gregory.woodhouse at gmail.com Thu May 17 10:45:29 2007 From: gregory.woodhouse at gmail.com (Woodhouse Gregory) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] VistA and HL7 In-Reply-To: <1179365179.7031.74.camel@oship> References: <1179362390.7031.70.camel@oship> <1179365179.7031.74.camel@oship> Message-ID: <541B3A02-7986-4293-AEBE-112957C41407@gmail.com> On May 16, 2007, at 6:26 PM, Tim Cook wrote: > On Wed, 2007-05-16 at 17:38 -0700, Tom Jones wrote: >> That is an interesting take on things. Everything I had ever heard >> about >> my-health-e-vet did not lead me to believe that it had aspirations to >> replace VistA. I rather thought that it was supposed to provide a >> patient >> view into VistA so that it could be represented as the PHR for >> veterans >> (that, of course, was a questionable view of PHR's) > > That is exactly what myHealth-e-Vet is/was. Also, as far as I know the > VistA interface was and is loved by many end-users. So I'm a bit > confused by the writing from Lee's student. Maybe I don't understand > the context it was written in? MyHealtheVet and HealtheVet are different things. MyHealtheVet is, indeed, a PHR. "In the human mind, one-sidedness has always been the rule and many-sidedness the exception. Hence, even in revolutions of thought, one part of the truth usually sets while another rises." --John Stuart Mill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/73e086ef/attachment.html From gregory.woodhouse at gmail.com Thu May 17 10:48:12 2007 From: gregory.woodhouse at gmail.com (Woodhouse Gregory) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] VistA and HL7 In-Reply-To: <464BA2B9.4020204@alum.mit.edu> References: <464BA2B9.4020204@alum.mit.edu> Message-ID: On May 16, 2007, at 5:32 PM, Lee Seldon wrote: > Here is a document describing (the original) VistA's involvement > with HL7 messaging. > http://www.va.gov/vdl/application.asp?appid=65 > Called "Generic HL7 Interface Handbook" > I assume that this would also apply to World VistA, but it would be > good to get confirmation from there. > Lee Yes. The HL7 software is the same in standard VistA (that's my own term for it) and the WorldVistA software. "Those who are enamored of practice without theory are like a pilot who goes into a ship without rudder or compass." --Leonardo da Vinci (1452-1519) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070516/d9eaf6e0/attachment.htm From dalmolin at worldvista.org Thu May 17 11:58:30 2007 From: dalmolin at worldvista.org (Joseph Dal Molin) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Re: VistA and HL7 In-Reply-To: <464BD07D.9020205@e-cology.ca> References: <464BD07D.9020205@e-cology.ca> Message-ID: <464BD2E6.5000504@worldvista.org> Joseph Dal Molin wrote: > WorldVistA EHR has all the integration capabilities of VistA, plus we > are using the Mirth integration engine. > > Joseph > From wwilson at umich.edu Thu May 17 23:39:44 2007 From: wwilson at umich.edu (Wayne Wilson) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] VistA and HL7 In-Reply-To: <464BA2B9.4020204@alum.mit.edu> References: <464BA2B9.4020204@alum.mit.edu> Message-ID: <00888808-6A77-4D79-B0E0-935E6052CE7C@umich.edu> A student wrote via Lee Seldon. > my-health-e-vet was to replace VistA) > I have not been following this area for some time, but years ago there was a movement to replace VistA. That movement got it's start within a program to integrate health data within the DOD. I think that replacement project hit many obstacles, technical and budgetary which slowed it way down. Maybe that project got transformed back into inter-operability? my-health-e-vet sounds a lot like a different system that would need to gain access to clinical data whether by front ending a system or pulling data from a system, so one could see that getting access to the Vista data, however that would be accomplished (directly, inter-op, replacement system) would be part of it's project plan. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070517/c339cabc/PGP.pgp From tw_cook at comcast.net Fri May 18 12:20:56 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Conference Results Message-ID: <1179462056.3590.80.camel@oship> All, One of the items that came out of the conference was the need for better research and information regarding the use of FOSS in health care. I agreed to head up this project but I need many to assist if you have some skills, access to literature and desire to do research. Even if you choose not to be actively involved in producing the documents please feel free to forward any and all information you may run across regarding actual implementation of FOSS in health care settings. Luciana Cavalini has offered to help with the study design and if there are other professional researchers available please pitch in. Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/da7883d6/attachment.pgp From drtushar.dey at gmail.com Fri May 18 15:33:30 2007 From: drtushar.dey at gmail.com (Dr. Tushar Dey) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <1179462056.3590.80.camel@oship> References: <1179462056.3590.80.camel@oship> Message-ID: <8e815f300705180033r3be0acfl995a70f0cc2c85bd@mail.gmail.com> Hi, I am unable to understand what project you are speaking. Can anu body help me please ? Thanks, Dr.Tusharkanti Dey On 5/18/07, Tim Cook wrote: > > All, > > One of the items that came out of the conference was the need for better > research and information regarding the use of FOSS in health care. > > I agreed to head up this project but I need many to assist if you have > some skills, access to literature and desire to do research. Even if > you choose not to be actively involved in producing the documents please > feel free to forward any and all information you may run across > regarding actual implementation of FOSS in health care settings. > > Luciana Cavalini has offered to help with the study design and if there > are other professional researchers available please pitch in. > > Regards, > Tim > > > -- > Timothy Cook, MSc > Health Informatics Research Services > http://home.comcast.net/~tw_cook/ > 01-904-322-8582 > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/a1174792/attachment.html From arin.basu at gmail.com Fri May 18 16:13:37 2007 From: arin.basu at gmail.com (Arindam Basu) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <1179462056.3590.80.camel@oship> References: <1179462056.3590.80.camel@oship> Message-ID: <464D6031.80506@gmail.com> Hi Tim: Count me in, if you will, in the project. I am a medical doctor (an Ear nose and throat surgeon) and an epidemiologist, and I am skilled in the following languages and have developed applications in open source: R for statistical computing, Linux/Apache/MySql/PHP/Python, and Ruby. I direct the Fogarty International Training Program on Environmental and Occupational Health in India and teach computing at West Bengal University of Technology for their management program, in addition to my clinical practice. Much of my work involves training and research of doctoral and post-doctoral level students in environmental and occupational health, and teaching them basics and advanced techniques of data analysis and graphics. I have been using and promoting Linux/OpenOffice/LaTeX suites well over the last five years, and would much like to see more FOSS implementation in health and medical care. Kind regards, Arin Basu Tim Cook wrote: > All, > > One of the items that came out of the conference was the need for better > research and information regarding the use of FOSS in health care. > > I agreed to head up this project but I need many to assist if you have > some skills, access to literature and desire to do research. Even if > you choose not to be actively involved in producing the documents please > feel free to forward any and all information you may run across > regarding actual implementation of FOSS in health care settings. > > Luciana Cavalini has offered to help with the study design and if there > are other professional researchers available please pitch in. > > Regards, > Tim > > > > ------------------------------------------------------------------------ > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From tw_cook at comcast.net Fri May 18 18:53:12 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <8e815f300705180033r3be0acfl995a70f0cc2c85bd@mail.gmail.com> References: <1179462056.3590.80.camel@oship> <8e815f300705180033r3be0acfl995a70f0cc2c85bd@mail.gmail.com> Message-ID: <1179485592.3590.89.camel@oship> On Fri, 2007-05-18 at 13:03 +0530, Dr. Tushar Dey wrote: > Hi, > > I am unable to understand what project you are speaking. Can anu body > help me please > ? > > Thanks, > Dr.Tusharkanti Dey > Dr. Dey, I am not speaking about a specific FOSS project. Instead we aim to perform a systematic review / meta-analysis on the use of any and all FOSS applications in health care. We expect to put together one or more academic papers on the subject in order to enhance the credibility of FOSS in the health informatics domain. Does this help explain the purpose of the study? Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/cdf9ae72/attachment.pgp From tw_cook at comcast.net Fri May 18 18:57:15 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:21 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <464D6031.80506@gmail.com> References: <1179462056.3590.80.camel@oship> <464D6031.80506@gmail.com> Message-ID: <1179485835.3590.94.camel@oship> On Fri, 2007-05-18 at 13:43 +0530, Arindam Basu wrote: > Hi Tim: > > Count me in, if you will, in the project. Excellent. I will compile a list of people that commit some resources to the project as well as what type of activities they will be doing. I expect that all of our communications will take place on this list and that there will be the other activities from the conference on here as well. The volume of email will serve to maintain a nice level of excitement. However, we may at some point, find a need to tag our subject lines with the a name for each activity. We'll play it by ear for now. Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/ecc79d39/attachment.pgp From tw_cook at comcast.net Fri May 18 19:00:08 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] OSCC Photos Message-ID: <1179486008.3590.97.camel@oship> The OSCC has put up some photos from our trip there on 12 May. See: http://gallery.oscc.org.my Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/0932dc93/attachment.pgp From tw_cook at comcast.net Sat May 19 07:58:45 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Research was: Conference Results In-Reply-To: <200705182350.l4INoAkD029114@svcstsnq08.hotspot.t-mobile.com> References: <200705182350.l4INoAkD029114@svcstsnq08.hotspot.t-mobile.com> Message-ID: <1179532725.25453.53.camel@oship> On Fri, 2007-05-18 at 16:50 -0700, Tom Jones wrote: > Were you aware of the attached articles? The first is focused on health > care; the second includes health care along with other industries; the third > covers open source use in a narrow domain in health care. > > Tom Thanks Tom. These are exactly the types of items that can benefit our systematic review. I was actually aware of 2 of the 3 but no matter. We can sort out duplicates easy enough. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/dda1f68f/attachment.pgp From tw_cook at comcast.net Sat May 19 08:01:20 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> Message-ID: <1179532880.25453.55.camel@oship> On Fri, 2007-05-18 at 16:54 -0700, Tom Jones wrote: > One more thing to look at > > Tom Excellent. I guess you volunteered to be on the research team? ;-) Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/2220c18a/attachment.pgp From tw_cook at comcast.net Sat May 19 08:15:20 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Study Framework In-Reply-To: <000501c798ae$178a0080$b406410a@itautecf8e5986> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> Message-ID: <1179533720.25453.63.camel@oship> Luciana, I know you are probably already working on a framework for this project but I just wanted to ask if you think a grounded theory approach is appropriate given that we will have a variety of inputs such as academic papers, white papers, presentations, podcasts, etc. ? Cheers, -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/5737352c/attachment.pgp From arin.basu at gmail.com Sat May 19 08:47:53 2007 From: arin.basu at gmail.com (Arindam Basu) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Study Framework In-Reply-To: <1179533720.25453.63.camel@oship> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> Message-ID: <464E4939.4000407@gmail.com> Hi Tim: I understand we may require a central "repository" kind of placeholder entity, where we can store all our "articles", "whitepapers", software or links to software, etc, and all other stuff that comes to mind related to this project some way down the project, if not right away. Are you planning to set up something like that already, or does something already exist specifically for this project that we can use? Something like, say a wiki, or an online database that can be updated collaboratively by several members? Opinions? /Arin Tim Cook wrote: > Luciana, > > I know you are probably already working on a framework for this project > but I just wanted to ask if you think a grounded theory approach is > appropriate given that we will have a variety of inputs such as academic > papers, white papers, presentations, podcasts, etc. ? > > Cheers, > > ------------------------------------------------------------------------ > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From drcheah at pc.jaring.my Sat May 19 09:53:34 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Study Framework In-Reply-To: <464E4939.4000407@gmail.com> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> Message-ID: <464E589E.8040208@pc.jaring.my> Dear Arindam, The OSHCA web-portal at http://oshca.org is meant to be organised to provide for this central "repository" for all OSHCA projects and initiatives. If its yet to acquire that capability, it will subsequently as one of the deliverables for the "Collaborative Grant" that OSHCA is refining for re-submission to IOSN ASEAN+3. All those who volunteered to be in charge of projects/ideas (whatever), please articulate what individual projects wish to have for their projects on the web-portal and the grant proposal will include that into the deliverables... We came up with a list on the 4th day of the conference and I'm waiting for Joseph to send that to me. Rgds, Molly Arindam Basu wrote: > Hi Tim: > > I understand we may require a central "repository" kind of placeholder > entity, where we can store all our "articles", "whitepapers", software > or links to software, etc, and all other stuff that comes to mind > related to this project some way down the project, if not right away. > Are you planning to set up something like that already, or does > something already exist specifically for this project that we can use? > Something like, say a wiki, or an online database that can be updated > collaboratively by several members? > > Opinions? > > /Arin > > > > Tim Cook wrote: > >> Luciana, >> >> I know you are probably already working on a framework for this project >> but I just wanted to ask if you think a grounded theory approach is >> appropriate given that we will have a variety of inputs such as academic >> papers, white papers, presentations, podcasts, etc. ? >> >> Cheers, >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> FOSS_health mailing list >> FOSS_health@oshca.org >> http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >> > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > From tw_cook at comcast.net Sat May 19 09:59:21 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Web Portal Issues was: Study Framework In-Reply-To: <464E4939.4000407@gmail.com> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> Message-ID: <1179539961.25453.82.camel@oship> The thought that I had on this was that we will use the OSHCA server. We have agreement from the Open Source Competency Center to host it (the new OSHCA server) there so it will have better bandwidth than where it is now. We also need to add a couple of additional Plone products and upgrade Plone. However, these activities really require someone on the ground there to download and install these products. I had intended to address this issue with Boh Heong Yap since he is in the area (same country at least) and had asked about the Wiki capability. I also have a query into the OSCC as to their ability to help in this regard. Certainly we need to relieve Molly of this burden. She has spent many hours of her own and certainly many pad staff hours to support this web presence. The parallel issue here is that if we are doing qualitative analysis then we really need a software package to do this. I like Atlas.ti but it can be quite expensive. I am looking into the free CDC application AnSWR but I have yet to be successful getting it installed and running. Does anyone know of other free / open source qualitative ananlysis software? Regards, Tim On Sat, 2007-05-19 at 06:17 +0530, Arindam Basu wrote: > Hi Tim: > > I understand we may require a central "repository" kind of placeholder > entity, where we can store all our "articles", "whitepapers", software > or links to software, etc, and all other stuff that comes to mind > related to this project some way down the project, if not right away. > Are you planning to set up something like that already, or does > something already exist specifically for this project that we can use? > Something like, say a wiki, or an online database that can be updated > collaboratively by several members? > > Opinions? > > /Arin > > > > Tim Cook wrote: > > Luciana, > > > > I know you are probably already working on a framework for this project > > but I just wanted to ask if you think a grounded theory approach is > > appropriate given that we will have a variety of inputs such as academic > > papers, white papers, presentations, podcasts, etc. ? > > > > Cheers, > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/eb735050/attachment.pgp From tw_cook at comcast.net Sat May 19 10:02:23 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Study Framework In-Reply-To: <464E589E.8040208@pc.jaring.my> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> <464E589E.8040208@pc.jaring.my> Message-ID: <1179540143.25453.86.camel@oship> On Sat, 2007-05-19 at 09:53 +0800, Molly Cheah wrote: > Dear Arindam, > > The OSHCA web-portal at http://oshca.org is meant to be organised to > provide for this central "repository" for all OSHCA projects and > initiatives. If its yet to acquire that capability, it will subsequently > as one of the deliverables for the "Collaborative Grant" that OSHCA is > refining for re-submission to IOSN ASEAN+3. Thanks Molly. > > All those who volunteered to be in charge of projects/ideas (whatever), > please articulate what individual projects wish to have for their > projects on the web-portal and the grant proposal will include that into > the deliverables... I'll compile that list for the research project immediately. > We came up with a list on the 4th day of the conference and I'm waiting > for Joseph to send that to me. I request that Joseph posts that list to this mailing lists as well. This will help involve everyone who could not be at that meeting. Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/09f8bb30/attachment.pgp From arin.basu at gmail.com Sat May 19 10:45:21 2007 From: arin.basu at gmail.com (Arindam Basu) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Re: Web Portal Issues was: Study Framework In-Reply-To: <1179539961.25453.82.camel@oship> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> <1179539961.25453.82.camel@oship> Message-ID: <464E64C1.80809@gmail.com> Hi Tim: Great to learn that a structure to archive and store essential resources is already in place, and ready to go. For qualitative data analysis software in open source, there are several choices: http://www.pressure.to/qda/ [Weft QDA] http://tamsys.sourceforge.net/ [Text Analysis Markup System Analyzer] I use R for statistical computing, which is open source, and several packages are available here as well from the CRAN repository: URI -- http://cran.r-project.org and search from there FactoMineR QCA pacakge LoopAnalyst SensoMineR and Stochmod Best, /Arin From dalmolin at e-cology.ca Thu May 17 11:48:13 2007 From: dalmolin at e-cology.ca (Joseph Dal Molin) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] VistA and HL7 Message-ID: <464BD07D.9020205@e-cology.ca> WorldVistA EHR has all the integration capabilities of VistA, plus we are using the Mirth integration engine. Joseph From au.jaiganesh at gmail.com Thu May 17 16:15:46 2007 From: au.jaiganesh at gmail.com (Jai Ganesh) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Re: [participants] OSHCA inter-operability list In-Reply-To: <464BBA2B.7060602@pc.jaring.my> References: <294404.24341.qm@web58709.mail.re1.yahoo.com> <464BBA2B.7060602@pc.jaring.my> Message-ID: Hello, I am keen to join this effort on interoperability. I am working as a project coordinator for implementing HIS, PACS and Telehealth projects of my institution which provides primary, secondary and tertiary care healthcare services besides rural outreach in India. I was a contributor to the National Taskforce for Telemedicine Standardisation in India. Looking forward to work on interoperability issues related to healthcare FOSS. Thank you very much. Regards Jai -- A.U.Jai Ganesh, MSc, MBA., Project Coordinator, Enterprise Healthcare Information systems, Sri Sathya Sai Health System. Prashanthi Nilayam. India. - Show quoted On 5/17/07, Molly Cheah wrote: > > Nandalal, > > I have forwarded your email to the FOSS_health@oshca.org list. Please > continue discussions on interoperability on that list. Appreciate your > co-operation on this so that it will be easier for OSHCA to monitor and > report on these activities later. > > I would like to request those who wanted to participate in the > interoperability test beds to subscribe to the FOSS_health@oshca.org > list asap. > > I will be re-submitting OSHCA's proposal for the Collaborative Grant to > IOSN+3 next week and I will rely on the discussions on that list to add > content and names of interested parties as partners to that grant > proposal. I will also outline what are needed in the grant proposal > particularly related to deliverables for the grant proposal. In other > words, FOSS_health@oshca.org will be our working environment for that > grant proposal with inputs from those who want to be part of that > proposal. > > Thank you. > > Rgds, > Molly > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070517/9dda713a/attachment.htm From chresearchcentre at yahoo.com Fri May 18 22:34:41 2007 From: chresearchcentre at yahoo.com (Mogere Dominic) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] re:" joining foss =-group discussion Message-ID: <823033.71223.qm@web58706.mail.re1.yahoo.com> We are a registered non profit making Organization- Kenya invoved in community health issues and here by express interest to join the discussion group [community health Research and consultancy international -Kericho,Kenya Contact Person: Dominic Mogere, ceo --------------------------------- 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/0da33a43/attachment.html From tom.jones at tolvenhealth.com Sat May 19 07:50:13 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <1179462056.3590.80.camel@oship> Message-ID: <200705182350.l4INoAkD029114@svcstsnq08.hotspot.t-mobile.com> Were you aware of the attached articles? The first is focused on health care; the second includes health care along with other industries; the third covers open source use in a narrow domain in health care. Tom -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of Tim Cook Sent: Thursday, May 17, 2007 9:21 PM To: FOSS Health Subject: [FOSS_health] Conference Results All, One of the items that came out of the conference was the need for better research and information regarding the use of FOSS in health care. I agreed to head up this project but I need many to assist if you have some skills, access to literature and desire to do research. Even if you choose not to be actively involved in producing the documents please feel free to forward any and all information you may run across regarding actual implementation of FOSS in health care settings. Luciana Cavalini has offered to help with the study design and if there are other professional researchers available please pitch in. Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenSourcePrimer.pdf Type: application/octet-stream Size: 324560 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/1b896bc4/OpenSourcePrimer.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: EC Open Source report.pdf Type: application/octet-stream Size: 1762858 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/1b896bc4/ECOpenSourcereport.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: open source de-identification paper.pdf Type: application/octet-stream Size: 361469 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/1b896bc4/opensourcede-identificationpaper.obj From tom.jones at tolvenhealth.com Sat May 19 07:54:03 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results Message-ID: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> One more thing to look at Tom -----Original Message----- From: Tom Jones [mailto:tom.jones@tolvenhealth.com] Sent: Friday, May 18, 2007 4:50 PM To: 'tw_cook@comcast.net'; 'foss_health@oshca.org' Subject: RE: [FOSS_health] Conference Results Were you aware of the attached articles? The first is focused on health care; the second includes health care along with other industries; the third covers open source use in a narrow domain in health care. Tom -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of Tim Cook Sent: Thursday, May 17, 2007 9:21 PM To: FOSS Health Subject: [FOSS_health] Conference Results All, One of the items that came out of the conference was the need for better research and information regarding the use of FOSS in health care. I agreed to head up this project but I need many to assist if you have some skills, access to literature and desire to do research. Even if you choose not to be actively involved in producing the documents please feel free to forward any and all information you may run across regarding actual implementation of FOSS in health care settings. Luciana Cavalini has offered to help with the study design and if there are other professional researchers available please pitch in. Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: Toward FOSS Health Care Systems Integration.pdf Type: application/octet-stream Size: 1000201 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070518/81fe9360/TowardFOSSHealthCareSystemsIntegration.obj From drcheah at pc.jaring.my Sat May 19 12:34:27 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Interoperability issues at HIMSS in Singapore a week after OSHCA 2007. Message-ID: <464E7E53.2030708@pc.jaring.my> This is a challenge to OSHCA's interoperability efforts. Please subscribe to FOSS_health@oshca.org to participate in the FOSS efforts co-ordinated by OSHCA. Go to http://mailman.oshca.org/mailman/listinfo.cgi/foss_health to subscribe. This is a follow-up to the OSHCA Conference 2007 with the Theme: "Moving the FOSS Agenda for Health: Setting the Framework for Interoperability" Molly http://www.zdnetasia.com/news/business/0,39044229,62013364,00.htm *Healthcare must step up IT adoption* By Isabelle Chan , ZDNet Asia Wednesday, May 16 2007 04:38 PM *SINGAPORE--Electronic medical records (EMR) may be a reality in some parts of the world today, but the healthcare sector would do well to adopt more information technologies so as to provide quality patient care.* Speaking at the opening of the first Healthcare Information and Management Systems Society (HIMSS) AsiaPac 2007 conference here Wednesday, Singapore's Minister for Health Khaw Boon Wan drove home the message that IT holds the key to containing rising healthcare costs and, at the same time, ensuing quality healthcare. "We all say that healthcare providers should treat patients holistically as a team, share information about the patients and partner one another to bring care to the patients, without duplicating efforts or replicating tests. "Yet, the reality is quite different," Khaw said. "Relatively few doctors, clinics and hospitals in the world consistently practise pro-active prevention regimes. Many chronically-ill are not receiving appropriate care at the appropriate level, and continue to be treated in more expensive tertiary settings unnecessarily." "Seamless, integrated care for patients across the whole healthcare ecosystem remains like the Holy Grail--widely sought by many, but still a distant, seemingly unattainable goal," he added. The minister called for greater adoption of IT, noting that the healthcare sector was a laggard compared to the high-tech manufacturing and financial services industries. "Healthcare, unfortunately, remains many steps behind other sectors," he said. From nandalalx at yahoo.com Sat May 19 15:50:45 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Study Framework In-Reply-To: <464E4939.4000407@gmail.com> Message-ID: <304026.85399.qm@web58709.mail.re1.yahoo.com> This is a good idea! --- Arindam Basu wrote: > Hi Tim: > > I understand we may require a central "repository" > kind of placeholder > entity, where we can store all our "articles", > "whitepapers", software > or links to software, etc, and all other stuff that > comes to mind > related to this project some way down the project, > if not right away. > Are you planning to set up something like that > already, or does > something already exist specifically for this > project that we can use? > Something like, say a wiki, or an online database > that can be updated > collaboratively by several members? > > Opinions? > > /Arin > > > > Tim Cook wrote: > > Luciana, > > > > I know you are probably already working on a > framework for this project > > but I just wanted to ask if you think a grounded > theory approach is > > appropriate given that we will have a variety of > inputs such as academic > > papers, white papers, presentations, podcasts, > etc. ? > > > > Cheers, > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________ Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather From nandalalx at yahoo.com Sat May 19 16:15:07 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Web Portal Issues was: Study Framework In-Reply-To: <1179539961.25453.82.camel@oship> Message-ID: <542666.68727.qm@web58708.mail.re1.yahoo.com> For qualitative analysis what you mention are the best. There is one which is free and open source listed in the oshca site of healthcare applications I put up using Tiddlywiki. It may not be as comprehensive as the ones you mention, but has a few basic features. Nandalal --- Tim Cook wrote: > > The thought that I had on this was that we will use > the OSHCA server. > We have agreement from the Open Source Competency > Center to host it (the > new OSHCA server) there so it will have better > bandwidth than where it > is now. We also need to add a couple of additional > Plone products and > upgrade Plone. However, these activities really > require someone on the > ground there to download and install these products. > I had intended to > address this issue with Boh Heong Yap since he is in > the area (same > country at least) and had asked about the Wiki > capability. I also have > a query into the OSCC as to their ability to help in > this regard. > > Certainly we need to relieve Molly of this burden. > She has spent many > hours of her own and certainly many pad staff hours > to support this web > presence. > > The parallel issue here is that if we are doing > qualitative analysis > then we really need a software package to do this. > I like Atlas.ti but > it can be quite expensive. I am looking into the > free CDC application > AnSWR but I have yet to be successful getting it > installed and > running. > > Does anyone know of other free / open source > qualitative ananlysis > software? > > Regards, > Tim > > > > > > On Sat, 2007-05-19 at 06:17 +0530, Arindam Basu > wrote: > > Hi Tim: > > > > I understand we may require a central "repository" > kind of placeholder > > entity, where we can store all our "articles", > "whitepapers", software > > or links to software, etc, and all other stuff > that comes to mind > > related to this project some way down the project, > if not right away. > > Are you planning to set up something like that > already, or does > > something already exist specifically for this > project that we can use? > > Something like, say a wiki, or an online database > that can be updated > > collaboratively by several members? > > > > Opinions? > > > > /Arin > > > > > > > > Tim Cook wrote: > > > Luciana, > > > > > > I know you are probably already working on a > framework for this project > > > but I just wanted to ask if you think a grounded > theory approach is > > > appropriate given that we will have a variety of > inputs such as academic > > > papers, white papers, presentations, podcasts, > etc. ? > > > > > > Cheers, > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > FOSS_health mailing list > > > FOSS_health@oshca.org > > > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > > > -- > Timothy Cook, MSc > Health Informatics Research Services > http://home.comcast.net/~tw_cook/ > 01-904-322-8582 > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From dalmolin at e-cology.ca Sun May 20 00:38:21 2007 From: dalmolin at e-cology.ca (Joseph Dal Molin) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Study Framework In-Reply-To: <464E589E.8040208@pc.jaring.my> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> <464E589E.8040208@pc.jaring.my> Message-ID: <464F27FD.80206@e-cology.ca> Here are the notes I took during the brainstorming workshop... apologies for the point form. Joseph Molly Cheah wrote: > Dear Arindam, > > The OSHCA web-portal at http://oshca.org is meant to be organised to > provide for this central "repository" for all OSHCA projects and > initiatives. If its yet to acquire that capability, it will subsequently > as one of the deliverables for the "Collaborative Grant" that OSHCA is > refining for re-submission to IOSN ASEAN+3. > > All those who volunteered to be in charge of projects/ideas (whatever), > please articulate what individual projects wish to have for their > projects on the web-portal and the grant proposal will include that into > the deliverables... > > We came up with a list on the 4th day of the conference and I'm waiting > for Joseph to send that to me. > > Rgds, > Molly > Arindam Basu wrote: > >> Hi Tim: >> >> I understand we may require a central "repository" kind of placeholder >> entity, where we can store all our "articles", "whitepapers", software >> or links to software, etc, and all other stuff that comes to mind >> related to this project some way down the project, if not right away. >> Are you planning to set up something like that already, or does >> something already exist specifically for this project that we can use? >> Something like, say a wiki, or an online database that can be updated >> collaboratively by several members? >> >> Opinions? >> >> /Arin >> >> >> >> Tim Cook wrote: >> >>> Luciana, >>> >>> I know you are probably already working on a framework for this project >>> but I just wanted to ask if you think a grounded theory approach is >>> appropriate given that we will have a variety of inputs such as academic >>> papers, white papers, presentations, podcasts, etc. ? >>> >>> Cheers, >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> FOSS_health mailing list >>> FOSS_health@oshca.org >>> http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >>> >> >> >> _______________________________________________ >> FOSS_health mailing list >> FOSS_health@oshca.org >> http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >> >> > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > . > -------------- next part -------------- A non-text attachment was scrubbed... Name: OSHCA Friday Workshop.odt Type: application/vnd.oasis.opendocument.text Size: 15952 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070519/d9fedcd9/OSHCAFridayWorkshop.bin From bhyz at mac.com Sun May 20 04:31:11 2007 From: bhyz at mac.com (Boh Heong Yap) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <1179539961.25453.82.camel@oship> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> <1179539961.25453.82.camel@oship> Message-ID: <20070519203111.26636@smtp.mac.com> hi Tim, Molly and all, Yes there seems to be a lot of things that such a "Resource Center" is supposed to do/to be. From the discussions so far, this is what seems to be needed (pls correct if I'm wrong) 1. Resource repository: a. presentations from OSHCA 2007 a repository for all presentation/workshop materials from the conference for download purposes. There should be the possibility for uploading (one time only, unless presenters update their material) and for downloading or viewing on line. b. FOSS in Health Care: Study Framework repositiory for articles, possibly as links with a short description, this could be set up as a SlashDot type list but more well cataloged/categorised and using a Wiki as a mechanism? see this as an example: of how articles can be listed, simple and clear and also enhance it by addding 'tags' to make it more easilly searchable. also wiki(s) to capture knowledge-base of the specific sub-areas id any. 2. OSHCA Interoperability project - nothing formalised yet here... but it could be a wiki definition of the project, its objectives, scope, timeline... - list of intended projects, ie: interoperability between SHANA and NetEPI (for e.g.), etc.. - list of intended Test-beds for the individual test beds... 3. OSHCA Human Resource list I remember talking briefly to someone at the conf. about this, but can't remember who, so perhaps I can suggest it here... We should collect the profiles and resume's of all OSHCA members, (and from what I have seen, its pretty impressive) this would not only give OSHCA great credibility, but such a list would be a great markeing tool/weapon even, when any of us need to present to the likes of government of private sector. Certainly proprietry advocates would find it hard enuff to drum up a similar list. This is something the big consultants do, and use to win business, we shld do the same.. ... there are quite a few more we can think of... Along with the above.. there are the ususal issues of access control, who can read, write/edit/upload data and so on. There may also be need for creations of groups for individual projects and the general sysadmin of all that, which can be a fair bit of work. I volunteer to help out with such work, but I cannot do it alone. As a freeelancer, my own projects take priority, as I do not have the cushion of a salary;-) Also how much resource we can get from OSCC I do not know. Molly, can you initiate a introduction via email and I can take it from there to asses the technical scope/capabilities... As Molly mentioned, we will need to upgrade and install apps., these require admin. privilages (or they can allow sudo/chroot etc..) and OSCC may not want to grant us such privilages ... remains to be seen. Another alternative is to just get space from them and use our own server (HW) and we can manage it completely. I can source unbranded Intel 1U servers from about 4k RM, config with Intel MB, 1Gb RAM, 2x250Gb HD. Also I do not know Plone, but shld be able to pick up given time... which is always in short supply;-) We need to discuss this further, and perhaps form a small team of ppl who can do sysadmin work and willing to contribute. Lets continue discussing this... maybe take this off the mail-list ? > >The thought that I had on this was that we will use the OSHCA server. >We have agreement from the Open Source Competency Center to host it (the >new OSHCA server) there so it will have better bandwidth than where it >is now. We also need to add a couple of additional Plone products and >upgrade Plone. However, these activities really require someone on the >ground there to download and install these products. I had intended to >address this issue with Boh Heong Yap since he is in the area (same >country at least) and had asked about the Wiki capability. I also have >a query into the OSCC as to their ability to help in this regard. > >Certainly we need to relieve Molly of this burden. She has spent many >hours of her own and certainly many pad staff hours to support this web >presence. > >The parallel issue here is that if we are doing qualitative analysis >then we really need a software package to do this. I like Atlas.ti but >it can be quite expensive. I am looking into the free CDC application >AnSWR but I have yet to be successful getting it installed and >running. > >Does anyone know of other free / open source qualitative ananlysis >software? > >Regards, >Tim > > > > > >On Sat, 2007-05-19 at 06:17 +0530, Arindam Basu wrote: >> Hi Tim: >> >> I understand we may require a central "repository" kind of placeholder >> entity, where we can store all our "articles", "whitepapers", software >> or links to software, etc, and all other stuff that comes to mind >> related to this project some way down the project, if not right away. >> Are you planning to set up something like that already, or does >> something already exist specifically for this project that we can use? >> Something like, say a wiki, or an online database that can be updated >> collaboratively by several members? >> >> Opinions? >> >> /Arin >> >> >> >> Tim Cook wrote: >> > Luciana, >> > >> > I know you are probably already working on a framework for this project >> > but I just wanted to ask if you think a grounded theory approach is >> > appropriate given that we will have a variety of inputs such as academic >> > papers, white papers, presentations, podcasts, etc. ? >> > >> > Cheers, >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > FOSS_health mailing list >> > FOSS_health@oshca.org >> > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >> > >> >-- >Timothy Cook, MSc >Health Informatics Research Services >http://home.comcast.net/~tw_cook/ >01-904-322-8582 >_______________________________________________ >FOSS_health mailing list >FOSS_health@oshca.org >http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From wfpearson at gmail.com Sun May 20 07:59:51 2007 From: wfpearson at gmail.com (William F Pearson III) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <20070519203111.26636@smtp.mac.com> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> <1179539961.25453.82.camel@oship> <20070519203111.26636@smtp.mac.com> Message-ID: <4765aee0705191659u3833dbd4qbda0d69de8f59806@mail.gmail.com> Just a quick reply. I was unable to attend the conference by I'm currently developing a Plone site for my employer. It will be a portal for physicians to communicate and a repository for information about their various committees. I can vouch for its easy of management as well as the ease of use. Feel free to email me if you have any questions about it. On 5/19/07, Boh Heong Yap wrote: > hi Tim, Molly and all, > > Yes there seems to be a lot of things that such a "Resource Center" is > supposed to do/to be. From the discussions so far, this is what seems to > be needed (pls correct if I'm wrong) > > 1. Resource repository: > a. presentations from OSHCA 2007 > a repository for all presentation/workshop materials from > the conference for download purposes. > There should be the possibility for uploading (one time only, > unless presenters update their material) and for downloading > or viewing on line. > > b. FOSS in Health Care: Study Framework > repositiory for articles, possibly as links with a short > description, this could be set up as a SlashDot type list but > more well cataloged/categorised and using a Wiki as a mechanism? > > see this as an example: of how articles can be listed, > simple and clear > > and also enhance it by addding 'tags' to make it more > easilly searchable. > > also wiki(s) to capture knowledge-base of the specific sub-areas > id any. > > 2. OSHCA Interoperability project > - nothing formalised yet here... but it could be a wiki definition > of the project, its objectives, scope, timeline... > > - list of intended projects, ie: > interoperability between SHANA and NetEPI (for e.g.), etc.. > > - list of intended Test-beds for the individual test beds... > > 3. OSHCA Human Resource list > > I remember talking briefly to someone at the conf. about this, > but can't remember who, so perhaps I can suggest it here... > > We should collect the profiles and resume's of all OSHCA members, > (and from what I have seen, its pretty impressive) this would > not only give OSHCA great credibility, but such a list would > be a great markeing tool/weapon even, when any of us need to > present to the likes of government of private sector. > Certainly proprietry advocates would find it hard enuff to > drum up a similar list. > > This is something the big consultants do, and use to win business, > we shld do the same.. > > ... there are quite a few more we can think of... > > Along with the above.. there are the ususal issues of access control, > who can read, write/edit/upload data and so on. There may also be need > for creations of groups for individual projects and the general sysadmin > of all that, which can be a fair bit of work. > > I volunteer to help out with such work, but I cannot do it alone. As a > freeelancer, my own projects take priority, as I do not have the cushion > of a salary;-) > > Also how much resource we can get from OSCC I do not know. Molly, can > you initiate a introduction via email and I can take it from there to > asses the technical scope/capabilities... > As Molly mentioned, we will need to upgrade and install apps., these > require admin. privilages (or they can allow sudo/chroot etc..) and OSCC > may not want to grant us such privilages ... remains to be seen. Another > alternative is to just get space from them and use our own server (HW) > and we can manage it completely. I can source unbranded Intel 1U servers > from about 4k RM, config with Intel MB, 1Gb RAM, 2x250Gb HD. > > Also I do not know Plone, but shld be able to pick up given time... > which is always in short supply;-) > > We need to discuss this further, and perhaps form a small team of ppl > who can do sysadmin work and willing to contribute. Lets continue > discussing this... maybe take this off the mail-list ? > > > >The thought that I had on this was that we will use the OSHCA server. > >We have agreement from the Open Source Competency Center to host it (the > >new OSHCA server) there so it will have better bandwidth than where it > >is now. We also need to add a couple of additional Plone products and > >upgrade Plone. However, these activities really require someone on the > >ground there to download and install these products. I had intended to > >address this issue with Boh Heong Yap since he is in the area (same > >country at least) and had asked about the Wiki capability. I also have > >a query into the OSCC as to their ability to help in this regard. > > > >Certainly we need to relieve Molly of this burden. She has spent many > >hours of her own and certainly many pad staff hours to support this web > >presence. > > > >The parallel issue here is that if we are doing qualitative analysis > >then we really need a software package to do this. I like Atlas.ti but > >it can be quite expensive. I am looking into the free CDC application > >AnSWR but I have yet to be successful getting it installed and > >running. > > > >Does anyone know of other free / open source qualitative ananlysis > >software? > > > >Regards, > >Tim > > > > > > > > > > > >On Sat, 2007-05-19 at 06:17 +0530, Arindam Basu wrote: > >> Hi Tim: > >> > >> I understand we may require a central "repository" kind of placeholder > >> entity, where we can store all our "articles", "whitepapers", software > >> or links to software, etc, and all other stuff that comes to mind > >> related to this project some way down the project, if not right away. > >> Are you planning to set up something like that already, or does > >> something already exist specifically for this project that we can use? > >> Something like, say a wiki, or an online database that can be updated > >> collaboratively by several members? > >> > >> Opinions? > >> > >> /Arin > >> > >> > >> > >> Tim Cook wrote: > >> > Luciana, > >> > > >> > I know you are probably already working on a framework for this project > >> > but I just wanted to ask if you think a grounded theory approach is > >> > appropriate given that we will have a variety of inputs such as academic > >> > papers, white papers, presentations, podcasts, etc. ? > >> > > >> > Cheers, > >> > > >> > ------------------------------------------------------------------------ > >> > > >> > _______________________________________________ > >> > FOSS_health mailing list > >> > FOSS_health@oshca.org > >> > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > >> > > >> > >-- > >Timothy Cook, MSc > >Health Informatics Research Services > >http://home.comcast.net/~tw_cook/ > >01-904-322-8582 > >_______________________________________________ > >FOSS_health mailing list > >FOSS_health@oshca.org > >http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > -- William F Pearson III From tw_cook at comcast.net Sun May 20 12:58:21 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <20070519203111.26636@smtp.mac.com> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> <1179539961.25453.82.camel@oship> <20070519203111.26636@smtp.mac.com> Message-ID: <1179637101.25453.215.camel@oship> Hi Boh, I will place replies in-line below but I wanted to let everyone know that some of these issues are taken care of solutions are in the works already. I hope my comments below help. On Sun, 2007-05-20 at 04:31 +0800, Boh Heong Yap wrote: > hi Tim, Molly and all, > > Yes there seems to be a lot of things that such a "Resource Center" is > supposed to do/to be. From the discussions so far, this is what seems to > be needed (pls correct if I'm wrong) > > 1. Resource repository: > a. presentations from OSHCA 2007 > a repository for all presentation/workshop materials from > the conference for download purposes. > There should be the possibility for uploading (one time only, > unless presenters update their material) and for downloading > or viewing on line. The Plone site (Plone is a python based content management application) is fully able to handle this. You can see that I have uploaded some of the presentations already. > > b. FOSS in Health Care: Study Framework > repositiory for articles, possibly as links with a short > description, this could be set up as a SlashDot type list but > more well cataloged/categorised and using a Wiki as a mechanism? > > see this as an example: of how articles can be listed, > simple and clear > > and also enhance it by addding 'tags' to make it more > easilly searchable. > > also wiki(s) to capture knowledge-base of the specific sub-areas > id any. Actually what we need here is simply a file repository. *IF** the analysis software will allow us to share a database then we may store that here as well. But in general I think we will only be storing source files here and exchange analysis information in other formats. Again, Plone provides for this out of the box. The tagging is taken care of because Plone provides for standard Dublin Core meta-data. one of those meta-data items is a subject or keyword list. They are part of every object stored in Plone. > 2. OSHCA Interoperability project > - nothing formalised yet here... but it could be a wiki definition > of the project, its objectives, scope, timeline... > > - list of intended projects, ie: > interoperability between SHANA and NetEPI (for e.g.), etc.. > > - list of intended Test-beds for the individual test beds... Could be a Wiki based project I guess. There is the ZWiki product that I have asked to be installed on the OSHCA server. It is the same one I installed for the local server at the conference. > 3. OSHCA Human Resource list > > I remember talking briefly to someone at the conf. about this, > but can't remember who, so perhaps I can suggest it here... > > We should collect the profiles and resume's of all OSHCA members, > (and from what I have seen, its pretty impressive) this would > not only give OSHCA great credibility, but such a list would > be a great markeing tool/weapon even, when any of us need to > present to the likes of government of private sector. > Certainly proprietry advocates would find it hard enuff to > drum up a similar list. I have requested the registered members list so that I can add each one to the portal. This would allow for each person to upload any document they wish to publish and one of the people with reviewers rights can determine if that document is suitable prior to it being published on the public website. > This is something the big consultants do, and use to win business, > we shld do the same.. This is true and as you suggested, could be a HUGE marketing tool. > ... there are quite a few more we can think of... > > Along with the above.. there are the ususal issues of access control, > who can read, write/edit/upload data and so on. There may also be need > for creations of groups for individual projects and the general sysadmin > of all that, which can be a fair bit of work. This is actually very easy in Plone. Zope (the underlying application server) has very fine grained access control and it is exposed in the Plone management interface. > I volunteer to help out with such work, but I cannot do it alone. As a > freeelancer, my own projects take priority, as I do not have the cushion > of a salary;-) I know that feeling well. :-) > Also how much resource we can get from OSCC I do not know. They have verbally agreed to host a server on site and provide at least basic admin support. > Molly, can > you initiate a introduction via email and I can take it from there to > asses the technical scope/capabilities... I spoke with Madam Tan King Ing and the center manager Jacob (sorry surname is not at hand) during the tour and they agreed that they could provide support for OSHCA. I have their cards and can send you their emails if you need them. > As Molly mentioned, we will need to upgrade and install apps., these > require admin. privilages (or they can allow sudo/chroot etc..) and OSCC > may not want to grant us such privilages ... remains to be seen. Another > alternative is to just get space from them and use our own server (HW) > and we can manage it completely. I can source unbranded Intel 1U servers > from about 4k RM, config with Intel MB, 1Gb RAM, 2x250Gb HD. Molly has told me tha tshe has funding for a server. One needs to be selected and purchased. > > Also I do not know Plone, but shld be able to pick up given time... > which is always in short supply;-) > > We need to discuss this further, and perhaps form a small team of ppl > who can do sysadmin work and willing to contribute. Lets continue > discussing this... maybe take this off the mail-list ? I believe all discussions should remain on list so that in case someone new needs to get involved they will have all the information. Myself and others are familiar with Plone. It is a very versatile and capable CMS. For some ppl it is overkill. For our needs I think it is just right. We can easily perform management tasks via the web but importing information and installing new products requires filesystem access; best done on a local level. I would be happy to walk any one through the process of installing the additional Plone products. Also I do not know what the competition can do but Plone comes with over 35 languages supported by it's i18n framework. In addition to the standard Plone objects, the following products should be installed: ZWiki Zwiki Folder AROfficeTransforms Conference Plone Templates (primarily for the FOSS products catalog) PloneMultimedia (included with newer versions of Plone) These are a handful of the products available: http://plone.org/products There is a lot of horsepower in Plone but it does have a bit more of a learning curve than some others. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070520/f13211a6/attachment.pgp From tw_cook at comcast.net Sun May 20 13:42:59 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Presentations Message-ID: <1179639779.25453.218.camel@oship> We are still missing the following presentations. If one or more are yours then please send it/them to conference@oshca.org Thank You, Tim Cook Title Session ID Legal issues impacting the use of open source software in health care Plenary #1 Health Information Governance Plenary #2 Debate: Proprietary vs. FOSS: Issues Plenary #3 MyOSCAR ? an Open Source Personally Controlled Health Record Session #1 The OpenMRS Collaborative ? Developing an Open Source Electronic Medical Record System and Integrated Healthcare Applications Session #2 Key to Sustainable Development in Thai Hospitals Session #3 Perspectives on the Opportunities and Issues of FOSS for Health Care Workers Session #7 Continuity of Business with VistA/GT.M/Linux Session #9 Free/Open Source Software (FOSS): Towards a post-capitalist society Session #10 Critical success factors for implementing open source IT infrastructure ? an experience sharing Session #11 Open-source Electronic Medical Record Building a support ecology, the OSCAR experience Session #12 Open Enterprise Master Person Index Session #13 Integration and Interoperability Experiences in Healthcare IT Session #15 HL7 Interoperability Standard Session #16 Mirth Implementation in VistA Session #17 Matching and Disclosure Choices of Person's Health Records Across Institutional and Political Boundaries Session #18 GT.M - the ideal database for your health care application Session #20 WorldVistA EHR: The Foundation For An Open Health Care Architecture Session #21 QEMU Virtual Machines - a fast and friendly way to create software appliances Session #22 Hemotology Lab System: A Live Case Stud Session #23 VistA Logical Schema and Some Future Directions Session #24 Implications of FOSS in improving physician acceptance of health care IT. Session #26 A Portable Problem-Oriented Electronic Health Record (PPOEHR) Session #27 NetEpi: free, open-source tools for epidemiology and disease outbreak investigation and control on the Internet. Session #28 R Statistics Application Session #29 Knowledge Sharing: Enriching Healthcare Knowledge and Practice through Peer Production Session #30 Hospital Management Information System (HMIS) Pakistan Institute of Medical Sciences (PIMS), A unique success story: Could we do better with Open Source software ? Session #31 GEM: The use of generic engine to develop modules by non-programmers Session #32 Care2x Session #33 Creating RDBMS-powered Content Management Systems with Plone Session #35 Building Communities of Practise ? IOSN Session #37 Sahana: FOSS Disaster Management System Workshop #1 Vista Office EHR (VOE) Registration Workshop #2 MUMPS Programming Workshop #3 Workshop #4 VistA FOSS Stack Clinic Workshop #5 Workshop #6 A Computerized Data Visualization Tool for Medical Data Analysis: A Case Study on Acute Stroke Patients Workshop #8 Developing an Integrated Medical Data Management Application for Handheld Computers using Two Open Source Applications, EpiHandy and OpenMRS Workshop #9 & #10 Securing health information using VPN Workshop #13 Why Use Postgresql for your next database-driven application? (And MySQL) Workshop #14 GT.M Database Technical Overview Workshop #15 Python Workshop #16 Ruby on Rails Workshop #17 Developing Health Applications using Frameworks: Experience with PHP-Cake Workshop #18 Implementing open source applications in the commercial world - an experience sharing [TENTATIVELY CANCELLED] Workshop #19 Standardizing Enterprise Desktop Deployments using LTSP Workshop #20 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070520/d9ba2a30/attachment.pgp From arin.basu at gmail.com Sun May 20 15:23:10 2007 From: arin.basu at gmail.com (Arindam Basu) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <1179637101.25453.215.camel@oship> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> <1179539961.25453.82.camel@oship> <20070519203111.26636@smtp.mac.com> <1179637101.25453.215.camel@oship> Message-ID: <464FF75E.4050607@gmail.com> Hi Tim and folks: Although I enjoy working with tikiwiki or MODx these days, I think Plone is a reasonable choice for a collaborative website -- reasonable but somewhat complicated. Plone is also extensible with python scripting, so if we do not like what we see in other software for our data analysis, we are free to write our own stuff! What I do not like in Plone is its somewhat dated., ugly look of the interface, and the complicated TALs (compared to that of textpattern or wordpress). Then again, the wiki system (Zwiki) is pretty much built in, and throw a blog in it if you will, and you have a great CMF/CMS to boot. What are the plans for setting up uniform search algorithms that people can follow to systematize literature retrieval? Which databases do we mine? Also, how about conducting several short publishable unit based lit reviews, as opposed to one, large joint publication with diverse subtopics? On a completely different note, I tried to register myself as a paying member at the OHSCA site, but was unsuccessful. What is the procedure to pay for memberships? Kind regards, Arin Tim Cook wrote: > Hi Boh, > > I will place replies in-line below but I wanted to let everyone know > that some of these issues are taken care of solutions are in the works > already. I hope my comments below help. > > On Sun, 2007-05-20 at 04:31 +0800, Boh Heong Yap wrote: > >> hi Tim, Molly and all, >> >> Yes there seems to be a lot of things that such a "Resource Center" is >> supposed to do/to be. From the discussions so far, this is what seems to >> be needed (pls correct if I'm wrong) >> >> 1. Resource repository: >> a. presentations from OSHCA 2007 >> a repository for all presentation/workshop materials from >> the conference for download purposes. >> There should be the possibility for uploading (one time only, >> unless presenters update their material) and for downloading >> or viewing on line. >> > > The Plone site (Plone is a python based content management application) > is fully able to handle this. You can see that I have uploaded some of > the presentations already. > > > > >> b. FOSS in Health Care: Study Framework >> repositiory for articles, possibly as links with a short >> description, this could be set up as a SlashDot type list but >> more well cataloged/categorised and using a Wiki as a mechanism? >> >> see this as an example: of how articles can be listed, >> simple and clear >> >> and also enhance it by addding 'tags' to make it more >> easilly searchable. >> >> also wiki(s) to capture knowledge-base of the specific sub-areas >> id any. >> > > Actually what we need here is simply a file repository. *IF** the > analysis software will allow us to share a database then we may store > that here as well. But in general I think we will only be storing > source files here and exchange analysis information in other formats. > > Again, Plone provides for this out of the box. The tagging is taken > care of because Plone provides for standard Dublin Core meta-data. one > of those meta-data items is a subject or keyword list. They are part of > every object stored in Plone. > > >> 2. OSHCA Interoperability project >> - nothing formalised yet here... but it could be a wiki definition >> of the project, its objectives, scope, timeline... >> >> - list of intended projects, ie: >> interoperability between SHANA and NetEPI (for e.g.), etc.. >> >> - list of intended Test-beds for the individual test beds... >> > > Could be a Wiki based project I guess. There is the ZWiki product that > I have asked to be installed on the OSHCA server. It is the same one I > installed for the local server at the conference. > > >> 3. OSHCA Human Resource list >> >> I remember talking briefly to someone at the conf. about this, >> but can't remember who, so perhaps I can suggest it here... >> >> We should collect the profiles and resume's of all OSHCA members, >> (and from what I have seen, its pretty impressive) this would >> not only give OSHCA great credibility, but such a list would >> be a great markeing tool/weapon even, when any of us need to >> present to the likes of government of private sector. >> Certainly proprietry advocates would find it hard enuff to >> drum up a similar list. >> > > I have requested the registered members list so that I can add each one > to the portal. This would allow for each person to upload any document > they wish to publish and one of the people with reviewers rights can > determine if that document is suitable prior to it being published on > the public website. > > > >> This is something the big consultants do, and use to win business, >> we shld do the same.. >> > > > This is true and as you suggested, could be a HUGE marketing tool. > > >> ... there are quite a few more we can think of... >> >> Along with the above.. there are the ususal issues of access control, >> who can read, write/edit/upload data and so on. There may also be need >> for creations of groups for individual projects and the general sysadmin >> of all that, which can be a fair bit of work. >> > > This is actually very easy in Plone. > Zope (the underlying application server) has very fine grained access > control and it is exposed in the Plone management interface. > > >> I volunteer to help out with such work, but I cannot do it alone. As a >> freeelancer, my own projects take priority, as I do not have the cushion >> of a salary;-) >> > > I know that feeling well. :-) > > >> Also how much resource we can get from OSCC I do not know. >> > > They have verbally agreed to host a server on site and provide at least > basic admin support. > > >> Molly, can >> you initiate a introduction via email and I can take it from there to >> asses the technical scope/capabilities... >> > > I spoke with Madam Tan King Ing and the center manager Jacob (sorry > surname is not at hand) during the tour and they agreed that they could > provide support for OSHCA. I have their cards and can send you their > emails if you need them. > > >> As Molly mentioned, we will need to upgrade and install apps., these >> require admin. privilages (or they can allow sudo/chroot etc..) and OSCC >> may not want to grant us such privilages ... remains to be seen. Another >> alternative is to just get space from them and use our own server (HW) >> and we can manage it completely. I can source unbranded Intel 1U servers >> from about 4k RM, config with Intel MB, 1Gb RAM, 2x250Gb HD. >> > > Molly has told me tha tshe has funding for a server. One needs to be > selected and purchased. > > >> Also I do not know Plone, but shld be able to pick up given time... >> which is always in short supply;-) >> >> We need to discuss this further, and perhaps form a small team of ppl >> who can do sysadmin work and willing to contribute. Lets continue >> discussing this... maybe take this off the mail-list ? >> > > I believe all discussions should remain on list so that in case someone > new needs to get involved they will have all the information. > > Myself and others are familiar with Plone. It is a very versatile and > capable CMS. For some ppl it is overkill. For our needs I think it is > just right. We can easily perform management tasks via the web but > importing information and installing new products requires filesystem > access; best done on a local level. I would be happy to walk any one > through the process of installing the additional Plone products. Also I > do not know what the competition can do but Plone comes with over 35 > languages supported by it's i18n framework. > > > In addition to the standard Plone objects, the following products should > be installed: > > ZWiki > Zwiki Folder > AROfficeTransforms > Conference > Plone Templates (primarily for the FOSS products catalog) > PloneMultimedia (included with newer versions of Plone) > > These are a handful of the products available: http://plone.org/products > > There is a lot of horsepower in Plone but it does have a bit more of a > learning curve than some others. > > > Cheers, > Tim > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From tw_cook at comcast.net Sun May 20 16:56:42 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Re: Presentations In-Reply-To: <1179639779.25453.218.camel@oship> References: <1179639779.25453.218.camel@oship> Message-ID: <1179651402.25453.237.camel@oship> On Sun, 2007-05-20 at 01:42 -0400, Tim Cook wrote: > We are still missing the following presentations. If one or more are > yours then please send it/them to conference@oshca.org The list I posted is INCORRECT. It contains all of the presentations not just the ones that are missing. My apologies I will ressend the missing items list later. Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070520/ff3e1191/attachment.pgp From ravindra at opensource.lk Fri May 18 16:54:28 2007 From: ravindra at opensource.lk (Ravindra De Silva) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Study Framework In-Reply-To: <464E4939.4000407@gmail.com> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> Message-ID: <1179478468.4024.11.camel@debian-ravi.r4vi.org> > I understand we may require a central "repository" kind of placeholder > entity, where we can store all our "articles", "whitepapers", software > or links to software, etc, and all other stuff that comes to mind > related to this project some way down the project, if not right away. > Are you planning to set up something like that already, or does > something already exist specifically for this project that we can use? > Something like, say a wiki, or an online database that can be updated > collaboratively by several members? if you are talking about a digital repository , the best i have encountered is Dspace (http://www.dspace.org/) . Its FOSS and a collaboration between MIT and Hewlett Packard. I have customized it and found to be very elegant. btw it uses the Dublin core meta data registry. How ever if you want a document management system, then check out KnowledgeTree (http://www.knowledgetree.com). cheers ravindra From dalmolin at e-cology.ca Sun May 20 23:13:09 2007 From: dalmolin at e-cology.ca (Joseph Dal Molin) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <464FF75E.4050607@gmail.com> References: <1179205359.3456.5.camel@oship> <005201c7972c$fb76a380$b406410a@itautecf8e5986> <1179338884.7031.48.camel@oship> <000501c798ae$178a0080$b406410a@itautecf8e5986> <1179533720.25453.63.camel@oship> <464E4939.4000407@gmail.com> <1179539961.25453.82.camel@oship> <20070519203111.26636@smtp.mac.com> <1179637101.25453.215.camel@oship> <464FF75E.4050607@gmail.com> Message-ID: <46506585.8060808@e-cology.ca> When an updated version of Plone is set up we should add the Plone Survey tool... it is a questionnaire building tool.... Joseph Arindam Basu wrote: > Hi Tim and folks: > > Although I enjoy working with tikiwiki or MODx these days, I think Plone > is a reasonable choice for a collaborative website -- reasonable but > somewhat complicated. Plone is also extensible with python scripting, > so if we do not like what we see in other software for our data > analysis, we are free to write our own stuff! > > What I do not like in Plone is its somewhat dated., ugly look of the > interface, and the complicated TALs (compared to that of textpattern or > wordpress). Then again, the wiki system (Zwiki) is pretty much built in, > and throw a blog in it if you will, and you have a great CMF/CMS to boot. > > What are the plans for setting up uniform search algorithms that people > can follow to systematize literature retrieval? Which databases do we > mine? Also, how about conducting several short publishable unit based > lit reviews, as opposed to one, large joint publication with diverse > subtopics? > > On a completely different note, I tried to register myself as a paying > member at the OHSCA site, but was unsuccessful. What is the procedure to > pay for memberships? > > Kind regards, > Arin > > > > Tim Cook wrote: >> Hi Boh, >> >> I will place replies in-line below but I wanted to let everyone know >> that some of these issues are taken care of solutions are in the works >> already. I hope my comments below help. >> >> On Sun, 2007-05-20 at 04:31 +0800, Boh Heong Yap wrote: >> >>> hi Tim, Molly and all, >>> >>> Yes there seems to be a lot of things that such a "Resource Center" is >>> supposed to do/to be. From the discussions so far, this is what seems to >>> be needed (pls correct if I'm wrong) >>> 1. Resource repository: >>> a. presentations from OSHCA 2007 >>> a repository for all presentation/workshop materials from >>> the conference for download purposes. >>> There should be the possibility for uploading (one time >>> only, >>> unless presenters update their material) and for >>> downloading or viewing on line. >>> >> >> The Plone site (Plone is a python based content management application) >> is fully able to handle this. You can see that I have uploaded some of >> the presentations already. >> >> >> >> >>> b. FOSS in Health Care: Study Framework >>> repositiory for articles, possibly as links with a short >>> description, this could be set up as a SlashDot type list >>> but more well cataloged/categorised and using a Wiki as a >>> mechanism? >>> >>> see this as an example: of how articles can be listed, >>> simple and clear >>> >>> and also enhance it by addding 'tags' to make it more >>> easilly searchable. >>> >>> also wiki(s) to capture knowledge-base of the specific >>> sub-areas >>> id any. >>> >> >> Actually what we need here is simply a file repository. *IF** the >> analysis software will allow us to share a database then we may store >> that here as well. But in general I think we will only be storing >> source files here and exchange analysis information in other formats. >> Again, Plone provides for this out of the box. The tagging is taken >> care of because Plone provides for standard Dublin Core meta-data. one >> of those meta-data items is a subject or keyword list. They are part of >> every object stored in Plone. >> >> >>> 2. OSHCA Interoperability project >>> - nothing formalised yet here... but it could be a wiki >>> definition of the project, its objectives, scope, >>> timeline... >>> - list of intended projects, ie: >>> interoperability between SHANA and NetEPI (for e.g.), etc.. >>> >>> - list of intended Test-beds for the individual test beds... >>> >> >> Could be a Wiki based project I guess. There is the ZWiki product that >> I have asked to be installed on the OSHCA server. It is the same one I >> installed for the local server at the conference. >> >> >>> 3. OSHCA Human Resource list >>> I remember talking briefly to someone at the >>> conf. about this, >>> but can't remember who, so perhaps I can suggest it here... >>> >>> We should collect the profiles and resume's of all OSHCA >>> members, (and from what I have seen, its pretty >>> impressive) this would not only give OSHCA great >>> credibility, but such a list would be a great markeing >>> tool/weapon even, when any of us need to present to the >>> likes of government of private sector. Certainly >>> proprietry advocates would find it hard enuff to drum up >>> a similar list. >>> >> >> I have requested the registered members list so that I can add each one >> to the portal. This would allow for each person to upload any document >> they wish to publish and one of the people with reviewers rights can >> determine if that document is suitable prior to it being published on >> the public website. >> >>> This is something the big consultants do, and use to win >>> business, we shld do the same.. >> >> >> This is true and as you suggested, could be a HUGE marketing tool. >> >> >>> ... there are quite a few more we can think of... >>> >>> Along with the above.. there are the ususal issues of access control, >>> who can read, write/edit/upload data and so on. There may also be need >>> for creations of groups for individual projects and the general sysadmin >>> of all that, which can be a fair bit of work. >>> >> >> This is actually very easy in Plone. >> Zope (the underlying application server) has very fine grained access >> control and it is exposed in the Plone management interface. >> >> >>> I volunteer to help out with such work, but I cannot do it alone. As a >>> freeelancer, my own projects take priority, as I do not have the cushion >>> of a salary;-) >>> >> >> I know that feeling well. :-) >> >> >>> Also how much resource we can get from OSCC I do not know. >> >> They have verbally agreed to host a server on site and provide at least >> basic admin support. >> >> >>> Molly, can >>> you initiate a introduction via email and I can take it from there to >>> asses the technical scope/capabilities... >>> >> >> I spoke with Madam Tan King Ing and the center manager Jacob (sorry >> surname is not at hand) during the tour and they agreed that they could >> provide support for OSHCA. I have their cards and can send you their >> emails if you need them. >> >> >>> As Molly mentioned, we will need to upgrade and install apps., these >>> require admin. privilages (or they can allow sudo/chroot etc..) and OSCC >>> may not want to grant us such privilages ... remains to be seen. Another >>> alternative is to just get space from them and use our own server (HW) >>> and we can manage it completely. I can source unbranded Intel 1U servers >>> from about 4k RM, config with Intel MB, 1Gb RAM, 2x250Gb HD. >> >> Molly has told me tha tshe has funding for a server. One needs to be >> selected and purchased. >> >> >>> Also I do not know Plone, but shld be able to pick up given time... >>> which is always in short supply;-) >>> >>> We need to discuss this further, and perhaps form a small team of ppl >>> who can do sysadmin work and willing to contribute. Lets continue >>> discussing this... maybe take this off the mail-list ? >>> >> >> I believe all discussions should remain on list so that in case someone >> new needs to get involved they will have all the information. >> >> Myself and others are familiar with Plone. It is a very versatile and >> capable CMS. For some ppl it is overkill. For our needs I think it is >> just right. We can easily perform management tasks via the web but >> importing information and installing new products requires filesystem >> access; best done on a local level. I would be happy to walk any one >> through the process of installing the additional Plone products. Also I >> do not know what the competition can do but Plone comes with over 35 >> languages supported by it's i18n framework. >> >> >> In addition to the standard Plone objects, the following products should >> be installed: >> >> ZWiki >> Zwiki Folder >> AROfficeTransforms Conference >> Plone Templates (primarily for the FOSS products catalog) >> PloneMultimedia (included with newer versions of Plone) >> >> These are a handful of the products available: http://plone.org/products >> >> There is a lot of horsepower in Plone but it does have a bit more of a >> learning curve than some others. >> >> >> Cheers, >> Tim >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> FOSS_health mailing list >> FOSS_health@oshca.org >> http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >> > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > . > From tchur at it.usyd.edu.au Mon May 21 10:44:47 2007 From: tchur at it.usyd.edu.au (Tim Churches) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] OSCC Photos In-Reply-To: <1179486008.3590.97.camel@oship> References: <1179486008.3590.97.camel@oship> Message-ID: <1179715487.5988.2.camel@tchur-laptop> On Fri, 2007-05-18 at 11:00 +0000, Tim Cook wrote: > The OSCC has put up some photos from our trip there on 12 May. > > See: http://gallery.oscc.org.my Oh dear, I look so fat in those photos.... (just because I am a nerdy geek doesn't mean I am not vain). But a great record of a memorable visit to a remarkable facility. If only we had such a centre here in Oz. Tim Churches Sydney, Australia From tchur at it.usyd.edu.au Mon May 21 11:59:23 2007 From: tchur at it.usyd.edu.au (Tim Churches) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <200705182350.l4INoAkD029114@svcstsnq08.hotspot.t-mobile.com> References: <200705182350.l4INoAkD029114@svcstsnq08.hotspot.t-mobile.com> Message-ID: <1179719963.5988.14.camel@tchur-laptop> On Fri, 2007-05-18 at 16:50 -0700, Tom Jones wrote: > Were you aware of the attached articles? The first is focused on health > care; the second includes health care along with other industries; the third > covers open source use in a narrow domain in health care. The Open Source in Health Primer is OK but it unfortunately perpetuates some myths about open source software. For example, it says: "Open source software is authored by small communities of developers who are committed to advancing health care IT but not directly compensated for their efforts.... Traditional vendors, in contrast, employ engineers to design software and programmers to write it." Clearly that is wrong - almost all significant open-source projects, including those in the health domain, are created by people who are paid or funded to do so and who are engineers, programmers or domain experts. The idea that open-source software is only created by enthusiastic amateurs in their spare time is a dangerous and counter-productive myth which should not be perpetuated. Hmmm, I have deja vu - I'm sure I expressed the same concerns about this same document previously - but Google can't find what I said. Pity the authors of the Primer document didn't release it under a Creative Commons or similar license - then we could have fixed the deficiencies and errors in it and it would have become a really useful resource. Tim C > -----Original Message----- > From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] > On Behalf Of Tim Cook > Sent: Thursday, May 17, 2007 9:21 PM > To: FOSS Health > Subject: [FOSS_health] Conference Results > > All, > > One of the items that came out of the conference was the need for better > research and information regarding the use of FOSS in health care. > > I agreed to head up this project but I need many to assist if you have > some skills, access to literature and desire to do research. Even if > you choose not to be actively involved in producing the documents please > feel free to forward any and all information you may run across > regarding actual implementation of FOSS in health care settings. > > Luciana Cavalini has offered to help with the study design and if there > are other professional researchers available please pitch in. > > Regards, > Tim > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From nsh at pop.jaring.my Mon May 21 10:42:40 2007 From: nsh at pop.jaring.my (Nah Soo Hoe) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <1179719963.5988.14.camel@tchur-laptop> References: <200705182350.l4INoAkD029114@svcstsnq08.hotspot.t-mobile.com> Message-ID: <465177A0.8377.10DE43@localhost> On 21 May 2007 at 11:59, Tim Churches wrote: > Pity the authors of the Primer document didn't release it under a > Creative Commons or similar license - then we could have fixed the > deficiencies and errors in it and it would have become a really useful > resource. UNDP/IOSN has a series of e-primers on FOSS that should be useful for people who are not familiar with FOSS and associated subject matter. The original primers can be downloaded from http://www.iosn.net/foss-primers These primers have also been made available on wikibooks and thus are available for updating and corrections, see: http://en.wikibooks.org/wiki/Category:FOSS_Books -- Soo Hoe From lutricav at vm.uff.br Mon May 21 15:17:11 2007 From: lutricav at vm.uff.br (Luciana Tricai Cavalini) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results References: <1179462056.3590.80.camel@oship> Message-ID: <002401c79b78$13a0e200$b406410a@itautecf8e5986> Hello Tim and all OSCHA colleagues, Yes, OSCHA can count on me for this activity. This is one of my main interests regarding my academic work. I'm ready to start working. All the best, Luciana Tricai Cavalini, MD, PhD Adjunct Professor, Fluminense Federal University, Brazil Visiting Researcher, Karolinska Institutet, Sweden **** All, One of the items that came out of the conference was the need for better research and information regarding the use of FOSS in health care. I agreed to head up this project but I need many to assist if you have some skills, access to literature and desire to do research. Even if you choose not to be actively involved in producing the documents please feel free to forward any and all information you may run across regarding actual implementation of FOSS in health care settings. Luciana Cavalini has offered to help with the study design and if there are other professional researchers available please pitch in. Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 ----- Original Message ----- From: "Tim Cook" To: "FOSS Health" Sent: Friday, May 18, 2007 1:20 AM Subject: [FOSS_health] Conference Results > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From lutricav at vm.uff.br Mon May 21 15:36:26 2007 From: lutricav at vm.uff.br (Luciana Tricai Cavalini) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results References: <1179462056.3590.80.camel@oship><8e815f300705180033r3be0acfl995a70f0cc2c85bd@mail.gmail.com> <1179485592.3590.89.camel@oship> Message-ID: <006801c79b7a$c36db210$b406410a@itautecf8e5986> Hello Tim, Dr. Dey, Dr. Basu and all OSCHA colleagues: I'm starting to write a structured abstract related to our project on systematic review/meta-analysis on FOSS x Healthcare. I think it is important for us to try to register it at Cochrane Database. It means that we must release a product of high quality. The only way is to perform it as a collaborative work. Maybe it could be important for us to design a research plan and a schedule. We will need two independent reviewers with expertise in systematic review. I could be one of them, but we must search for the second one. All other researchers engaged in this activity should help in finding articles and other references not available at reviewer's local libraries (it is not a hard task; here in Karolinska Institutet we have access to virtually all scientific literature all around the world - but sometimes we have some surprises performing systematic review). I'm here only speaking freely, OK? All the best, Luciana. ***** ----- Original Message ----- From: "Tim Cook" To: "Dr. Tushar Dey" Cc: Sent: Friday, May 18, 2007 7:53 AM Subject: Re: [FOSS_health] Conference Results > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From lutricav at vm.uff.br Mon May 21 15:51:47 2007 From: lutricav at vm.uff.br (Luciana Tricai Cavalini) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> <1179532880.25453.55.camel@oship> Message-ID: <008a01c79b7c$e8955820$b406410a@itautecf8e5986> Hello all, Warning: sharing articles related to the systematic review before defining the review strategy can bias the results. Independent reviewers are supposed to start from zero and strictly obey the defined strategy. It means that if one of us wants to be one of the two independent reviewers, he/she is not allowed to open the articles attached to the messages related to this subject on FOSS_health mailing list. Otherwise Cochrane will probably say "no" to our registration request. Please, forgive me, but I'm only trying to help. If I am not helping, please tell me. All the best, Luciana. ----- Original Message ----- From: "Tim Cook" To: "Tom Jones" Cc: Sent: Friday, May 18, 2007 9:01 PM Subject: RE: [FOSS_health] Conference Results > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From tw_cook at comcast.net Mon May 21 16:00:17 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <008a01c79b7c$e8955820$b406410a@itautecf8e5986> References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> <1179532880.25453.55.camel@oship> <008a01c79b7c$e8955820$b406410a@itautecf8e5986> Message-ID: <1179734417.27292.45.camel@oship> Luciana, You are being very helpful. We do not want to contaminate the study. It is one reason why I was very happy to have you volunteer to design and consult on the process. I have just asked a world wide known expert in health informatics to be our second reviewer. As soon as I have a response to whether this researcher has the resource available to help I will let you all know. BTW: This researcher is knowledgeable though not active in the FOSS community. Cheers, Tim On Mon, 2007-05-21 at 04:51 -0300, Luciana Tricai Cavalini wrote: > Hello all, > > Warning: sharing articles related to the systematic review before defining > the review strategy can bias the results. Independent reviewers are supposed > to start from zero and strictly obey the defined strategy. It means that if > one of us wants to be one of the two independent reviewers, he/she is not > allowed to open the articles attached to the messages related to this > subject on FOSS_health mailing list. Otherwise Cochrane will probably say > "no" to our registration request. > > Please, forgive me, but I'm only trying to help. If I am not helping, please > tell me. > > All the best, > > Luciana. > > ----- Original Message ----- > From: "Tim Cook" > To: "Tom Jones" > Cc: > Sent: Friday, May 18, 2007 9:01 PM > Subject: RE: [FOSS_health] Conference Results > > > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070521/e853b58d/attachment.pgp From davidhcchan at yahoo.com Tue May 22 01:35:49 2007 From: davidhcchan at yahoo.com (David Chan) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Resource Center: for Study Framework etc.. Message-ID: <828579.24077.qm@web30503.mail.mud.yahoo.com> We are running Plone 2.5.x hosting our own departmental web-site as well as a number of projects. We would be more than happy to add OSHCA to it. Our server is at ServerBeach in the US (http://www.serverbeach.com/) with lots of bandwidth. I would be willing to host it for free. Just a sample of our projects on the Plone site: http://fammed.mcmaster.ca http://stonechurchclinic.ca http://qualityinfamilypractice.com and of course our FOSS projects! http://oscarmcmaster.org http://res.oscarmcmaster.org http://ebm.oscarmcmaster.org http://myoscar.org Have a nice visit! David David H Chan, MD, CCFP, MSc, FCFP Associate Professor Department of Family Medicine McMaster University ----- Original Message ---- From: Tim Cook To: Boh Heong Yap Cc: foss_health@oshca.org Sent: Sunday, May 20, 2007 12:58:21 AM Subject: Re: [FOSS_health] Resource Center: for Study Framework etc.. Hi Boh, I will place replies in-line below but I wanted to let everyone know that some of these issues are taken care of solutions are in the works already. I hope my comments below help. On Sun, 2007-05-20 at 04:31 +0800, Boh Heong Yap wrote: > hi Tim, Molly and all, > > Yes there seems to be a lot of things that such a "Resource Center" is > supposed to do/to be. From the discussions so far, this is what seems to > be needed (pls correct if I'm wrong) > > 1. Resource repository: > a. presentations from OSHCA 2007 > a repository for all presentation/workshop materials from > the conference for download purposes. > There should be the possibility for uploading (one time only, > unless presenters update their material) and for downloading > or viewing on line. The Plone site (Plone is a python based content management application) is fully able to handle this. You can see that I have uploaded some of the presentations already. > > b. FOSS in Health Care: Study Framework > repositiory for articles, possibly as links with a short > description, this could be set up as a SlashDot type list but > more well cataloged/categorised and using a Wiki as a mechanism? > > see this as an example: of how articles can be listed, > simple and clear > > and also enhance it by addding 'tags' to make it more > easilly searchable. > > also wiki(s) to capture knowledge-base of the specific sub-areas > id any. Actually what we need here is simply a file repository. *IF** the analysis software will allow us to share a database then we may store that here as well. But in general I think we will only be storing source files here and exchange analysis information in other formats. Again, Plone provides for this out of the box. The tagging is taken care of because Plone provides for standard Dublin Core meta-data. one of those meta-data items is a subject or keyword list. They are part of every object stored in Plone. > 2. OSHCA Interoperability project > - nothing formalised yet here... but it could be a wiki definition > of the project, its objectives, scope, timeline... > > - list of intended projects, ie: > interoperability between SHANA and NetEPI (for e.g.), etc.. > > - list of intended Test-beds for the individual test beds... Could be a Wiki based project I guess. There is the ZWiki product that I have asked to be installed on the OSHCA server. It is the same one I installed for the local server at the conference. > 3. OSHCA Human Resource list > > I remember talking briefly to someone at the conf. about this, > but can't remember who, so perhaps I can suggest it here... > > We should collect the profiles and resume's of all OSHCA members, > (and from what I have seen, its pretty impressive) this would > not only give OSHCA great credibility, but such a list would > be a great markeing tool/weapon even, when any of us need to > present to the likes of government of private sector. > Certainly proprietry advocates would find it hard enuff to > drum up a similar list. I have requested the registered members list so that I can add each one to the portal. This would allow for each person to upload any document they wish to publish and one of the people with reviewers rights can determine if that document is suitable prior to it being published on the public website. > This is something the big consultants do, and use to win business, > we shld do the same.. This is true and as you suggested, could be a HUGE marketing tool. > ... there are quite a few more we can think of... > > Along with the above.. there are the ususal issues of access control, > who can read, write/edit/upload data and so on. There may also be need > for creations of groups for individual projects and the general sysadmin > of all that, which can be a fair bit of work. This is actually very easy in Plone. Zope (the underlying application server) has very fine grained access control and it is exposed in the Plone management interface. > I volunteer to help out with such work, but I cannot do it alone. As a > freeelancer, my own projects take priority, as I do not have the cushion > of a salary;-) I know that feeling well. :-) > Also how much resource we can get from OSCC I do not know. They have verbally agreed to host a server on site and provide at least basic admin support. > Molly, can > you initiate a introduction via email and I can take it from there to > asses the technical scope/capabilities... I spoke with Madam Tan King Ing and the center manager Jacob (sorry surname is not at hand) during the tour and they agreed that they could provide support for OSHCA. I have their cards and can send you their emails if you need them. > As Molly mentioned, we will need to upgrade and install apps., these > require admin. privilages (or they can allow sudo/chroot etc..) and OSCC > may not want to grant us such privilages ... remains to be seen. Another > alternative is to just get space from them and use our own server (HW) > and we can manage it completely. I can source unbranded Intel 1U servers > from about 4k RM, config with Intel MB, 1Gb RAM, 2x250Gb HD. Molly has told me tha tshe has funding for a server. One needs to be selected and purchased. > > Also I do not know Plone, but shld be able to pick up given time... > which is always in short supply;-) > > We need to discuss this further, and perhaps form a small team of ppl > who can do sysadmin work and willing to contribute. Lets continue > discussing this... maybe take this off the mail-list ? I believe all discussions should remain on list so that in case someone new needs to get involved they will have all the information. Myself and others are familiar with Plone. It is a very versatile and capable CMS. For some ppl it is overkill. For our needs I think it is just right. We can easily perform management tasks via the web but importing information and installing new products requires filesystem access; best done on a local level. I would be happy to walk any one through the process of installing the additional Plone products. Also I do not know what the competition can do but Plone comes with over 35 languages supported by it's i18n framework. In addition to the standard Plone objects, the following products should be installed: ZWiki Zwiki Folder AROfficeTransforms Conference Plone Templates (primarily for the FOSS products catalog) PloneMultimedia (included with newer versions of Plone) These are a handful of the products available: http://plone.org/products There is a lot of horsepower in Plone but it does have a bit more of a learning curve than some others. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ From amidgley at defoam.net Tue May 22 07:30:11 2007 From: amidgley at defoam.net (Adrian Midgley) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <1179719963.5988.14.camel@tchur-laptop> References: <200705182350.l4INoAkD029114@svcstsnq08.hotspot.t-mobile.com> <1179719963.5988.14.camel@tchur-laptop> Message-ID: <46522B83.8040805@defoam.net> Tim Churches wrote: > The Open Source in Health Primer is OK but it unfortunately perpetuates > some myths about open source software. For example, it says: > > We could offer them assistance in producing a second edition, perhaps. -- A From ravindra at opensource.lk Sun May 20 09:08:28 2007 From: ravindra at opensource.lk (Ravindra De Silva) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] OSCC Photos In-Reply-To: <1179715487.5988.2.camel@tchur-laptop> References: <1179486008.3590.97.camel@oship> <1179715487.5988.2.camel@tchur-laptop> Message-ID: <1179623308.4113.18.camel@debian-ravi.r4vi.org> > But a great record of a memorable visit to a remarkable facility. If > only we had such a centre here in Oz. > Hi Tim, glad to hear you back in the mailing list :) I hope you remember me , i am Ravindra from the SAHANA team. it was a pleasure meeting you and out of the many wonderful stuff i learned from the OSCHA , i learned about NetEpi. As a follow up, I really would like to see the possibility of integration of NetEpi with SAHANA and i already sent you few emails last week. I hope you will have time to reply. thanks and regards ravindra From tw_cook at comcast.net Tue May 22 14:03:36 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <1179734417.27292.45.camel@oship> References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> <1179532880.25453.55.camel@oship> <008a01c79b7c$e8955820$b406410a@itautecf8e5986> <1179734417.27292.45.camel@oship> Message-ID: <1179813816.3545.95.camel@oship> On Mon, 2007-05-21 at 08:00 +0000, Tim Cook wrote: > I have just asked a world wide known expert in health informatics to be > our second reviewer. As soon as I have a response to whether this > researcher has the resource available to help I will let you all know. > > BTW: This researcher is knowledgeable though not active in the FOSS > community. This researcher does not have time to help with the study but is willing to review our work. So I am not certain what was actually needed. Luciana can you elaborate on your email? regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070522/5e5a7a76/attachment.pgp From tchur at it.usyd.edu.au Tue May 22 16:15:14 2007 From: tchur at it.usyd.edu.au (Tim Churches) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <1179813816.3545.95.camel@oship> References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> <1179532880.25453.55.camel@oship> <008a01c79b7c$e8955820$b406410a@itautecf8e5986> <1179734417.27292.45.camel@oship> <1179813816.3545.95.camel@oship> Message-ID: <1179821714.5988.154.camel@tchur-laptop> On Tue, 2007-05-22 at 02:03 -0400, Tim Cook wrote: > On Mon, 2007-05-21 at 08:00 +0000, Tim Cook wrote: > > > I have just asked a world wide known expert in health informatics to be > > our second reviewer. As soon as I have a response to whether this > > researcher has the resource available to help I will let you all know. > > > > BTW: This researcher is knowledgeable though not active in the FOSS > > community. > > > This researcher does not have time to help with the study but is willing > to review our work. So I am not certain what was actually needed. > Luciana can you elaborate on your email? I think that Luciana's thorough and principled approach is admirable, but I suggest that a bit of searching on PubMed and Google is needed first (the theoretical risk of bias of the meta-analysis notwithstanding), because I suspect that there is actually very little in the "black literature" (that is, formally published papers in the peer-reviewed biomedical literature) on open-source in health, and what is there is probably descriptive rather than evaluative or comparative. There is a lot more in the "grey literature", mostly self-published Web sites and some non peer-reviewed reports, but again most will be descriptive rather than comparative. However, I might be wrong, but I suggest looking to see how many suitable studies there are first. If there are too few, then perhaps the study question will need to be broadened ie. not just comparison (of some aspects of) open-source versus closed-source health software. Tim Churches From tw_cook at comcast.net Tue May 22 15:11:11 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <1179821714.5988.154.camel@tchur-laptop> References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> <1179532880.25453.55.camel@oship> <008a01c79b7c$e8955820$b406410a@itautecf8e5986> <1179734417.27292.45.camel@oship> <1179813816.3545.95.camel@oship> <1179821714.5988.154.camel@tchur-laptop> Message-ID: <1179817871.3545.118.camel@oship> Hi Tim, Thanks for those very good points. In some ways though I believe you may be ahead of where we are (or at least where I am). We haven't formally defined a research question yet and we also have a suggestion to maybe break things down into multiple categories and produce multiple papers. Time is certainly a crucial element. Do we want to move quickly taking advantage of momentum? How much time can each participant contribute? So after defining one or more question(s) a schedule is a good idea, as Luciana suggested. You are likely correct about the black lit. but there are MANY papers that have been peer reviewed for conferences. Informatics is still a new field and most of the papers are going to be found in conference proceedings. As you indicated though most of them will not be evaluative or comparative. This is why I suggested that we look at doing a qualitative review of what is available so that we may make a little sense of what has been presented. There are many things that can emerge out of a good qualitative study on conference papers. Probably one of the most important things would be that one could establish a basis for funding a comparative study between open and closed source implementations. I personally think that such a study would be valueless but I am also aware that many people "need" to see those kinds of studies. Anyway, my intent in this reply was to offer a formal research question suggestion and gather some feedback on it. "Is free and open source software effective in healthcare information management?" Not more so or better than proprietary. Just is it effective? Thoughts? Cheers, Tim Cook On Tue, 2007-05-22 at 16:15 +0800, Tim Churches wrote: > On Tue, 2007-05-22 at 02:03 -0400, Tim Cook wrote: > > On Mon, 2007-05-21 at 08:00 +0000, Tim Cook wrote: > > > > > I have just asked a world wide known expert in health informatics to be > > > our second reviewer. As soon as I have a response to whether this > > > researcher has the resource available to help I will let you all know. > > > > > > BTW: This researcher is knowledgeable though not active in the FOSS > > > community. > > > > > > This researcher does not have time to help with the study but is willing > > to review our work. So I am not certain what was actually needed. > > Luciana can you elaborate on your email? > > I think that Luciana's thorough and principled approach is admirable, > but I suggest that a bit of searching on PubMed and Google is needed > first (the theoretical risk of bias of the meta-analysis > notwithstanding), because I suspect that there is actually very little > in the "black literature" (that is, formally published papers in the > peer-reviewed biomedical literature) on open-source in health, and what > is there is probably descriptive rather than evaluative or comparative. > There is a lot more in the "grey literature", mostly self-published Web > sites and some non peer-reviewed reports, but again most will be > descriptive rather than comparative. However, I might be wrong, but I > suggest looking to see how many suitable studies there are first. If > there are too few, then perhaps the study question will need to be > broadened ie. not just comparison (of some aspects of) open-source > versus closed-source health software. > > Tim Churches > > > -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070522/7cb42d50/attachment.pgp From lutricav at vm.uff.br Tue May 22 20:42:32 2007 From: lutricav at vm.uff.br (Luciana Tricai Cavalini) Date: Sun Jan 27 17:55:22 2008 Subject: [FOSS_health] Research Question was:Conference Results References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com><1179532880.25453.55.camel@oship><008a01c79b7c$e8955820$b406410a@itautecf8e5986><1179734417.27292.45.camel@oship> <1179813816.3545.95.camel@oship><1179821714.5988.154.camel@tchur-laptop> <1179817871.3545.118.camel@oship> Message-ID: <003201c79c6e$b1dbb4d0$b406410a@itautecf8e5986> Hello Tim, Tim and all, I'm sorry if I am being persistent, but I think we should make some effort in order to perform a formal systematic review (SR from now on) after giving up and shift to an expanded review. If we were registered at Cochrane Database (CochDb from now on), our searching for evidence will be safely stored and when the mission is accomplished, we are supposed to be acknowledged by the global scientific community. It is not just a sort of "label": I'm here talking about an empowering strategy which can enrich the results of our efforts. We can be audacious and purpose the inclusion of "black" and "grey" literature in our SR, according to Dr. Churches' suggestion. This is a challenge but it is a good one; I was thinking the same way. Our subject has some specificity that can't be ignored. This can bring some resistance to our CochDb registration but I think it is a good bet and brings relative originality to our project. Dr. Churches raised some methodological issues I was thinking about last night. What is our objective? Search for evidence on FOSS solutions efficacy/efficiency/effectiveness in health compared to what? (1) FOSS x commercial solutions? That's questionable; one can say that we can be only comparing two inefficient interventions. Probably this study should be registered at CochDb only as an econometric study (because the only thing remaining is cost analysis). It is not that bad at all; this is important for decision-makers, and they are obviously our clients. (2) FOSS x no IT intervention? In technical terms, quasi-experimental studies? This is closer to the ideal, but searching for these studies is probably an arid task. I suspect we will find sparse studies designed this way. By the way, I think we should ***prepare ourselves to perform this kind of study***. In other words: if the evidence doesn't exist, we must build it. But it requires strong collaborative work. I would like not to talk about which "official" databases we could search for in order to perform the SR first step, because, both reviewers must reach to an agreement on it, and ***it takes part of the SR process***, thus it means that ***must be documented*** at the structured abstract; but these are not the latest news down the square: Cochrane Collaboration has defined strict guidelines on it, all we have to do is to follow them. (I think all this stuff can be arid for some of us, but unfortunately nowadays science may seem -but only seem - a kind of strait jacket. The problem is: we are well intentioned, but how many are not? Think about tobacco industry-sponsored studies during the 1980's, and subscribed by some of the most famous epidemiologists in the world, stating that coffee, and not cigarettes, was the real villain?) Best regards, Luciana. ----- Original Message ----- From: "Tim Cook" To: "FOSS Health" Sent: Tuesday, May 22, 2007 4:11 AM Subject: [FOSS_health] Research Question was:Conference Results > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From lutricav at vm.uff.br Tue May 22 22:08:28 2007 From: lutricav at vm.uff.br (Luciana Tricai Cavalini) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com><1179532880.25453.55.camel@oship><008a01c79b7c$e8955820$b406410a@itautecf8e5986><1179734417.27292.45.camel@oship> <1179813816.3545.95.camel@oship><1179821714.5988.154.camel@tchur-laptop> <1179817871.3545.118.camel@oship> Message-ID: <009c01c79c7a$b19f0380$b406410a@itautecf8e5986> Hello Tim, Tim and all, If time is a concern, I fear it is possible to put in risk the quality of the work. Building knowledge is a task which requires reflection and planning (and some consensus among stakeholders), and ***it takes time***. Remember our enemies are hegemonic and they will beat us to death if we fail once. Note: conference abstracts ***are supposed to*** enter any SR. Dr. Churches, I am honored to invite you to be our first reviewer (I would be the second). Please, feel absolutely free to use all the time you need to think about it and to say no if it is not at your horizon of interests. Best regards, Luciana. ----- Original Message ----- From: "Tim Cook" To: "FOSS Health" Sent: Tuesday, May 22, 2007 4:11 AM Subject: [FOSS_health] Research Question was:Conference Results > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From davidhcchan at yahoo.com Tue May 22 20:14:03 2007 From: davidhcchan at yahoo.com (David Chan) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results Message-ID: <544364.56736.qm@web30502.mail.mud.yahoo.com> Dr. Tomislav Svoboda, Dr. Alex Jadad, and I have previously submitted a registration application to Cochrane for this title: Review of Advantages and Disadvantages of Open versus Close Source System Software in health care related information technology solutions We haven't started the work formally yet. It seems that if there is sufficient interest in this group, we should collaborate. David David H Chan, MD, CCFP, MSc, FCFP Associate Professor Department of Family Medicine McMaster University ----- Original Message ---- From: Luciana Tricai Cavalini To: tw_cook@comcast.net; foss_health@oshca.org Sent: Tuesday, May 22, 2007 8:42:32 AM Subject: Re: [FOSS_health] Research Question was:Conference Results Hello Tim, Tim and all, I'm sorry if I am being persistent, but I think we should make some effort in order to perform a formal systematic review (SR from now on) after giving up and shift to an expanded review. If we were registered at Cochrane Database (CochDb from now on), our searching for evidence will be safely stored and when the mission is accomplished, we are supposed to be acknowledged by the global scientific community. It is not just a sort of "label": I'm here talking about an empowering strategy which can enrich the results of our efforts. We can be audacious and purpose the inclusion of "black" and "grey" literature in our SR, according to Dr. Churches' suggestion. This is a challenge but it is a good one; I was thinking the same way. Our subject has some specificity that can't be ignored. This can bring some resistance to our CochDb registration but I think it is a good bet and brings relative originality to our project. Dr. Churches raised some methodological issues I was thinking about last night. What is our objective? Search for evidence on FOSS solutions efficacy/efficiency/effectiveness in health compared to what? (1) FOSS x commercial solutions? That's questionable; one can say that we can be only comparing two inefficient interventions. Probably this study should be registered at CochDb only as an econometric study (because the only thing remaining is cost analysis). It is not that bad at all; this is important for decision-makers, and they are obviously our clients. (2) FOSS x no IT intervention? In technical terms, quasi-experimental studies? This is closer to the ideal, but searching for these studies is probably an arid task. I suspect we will find sparse studies designed this way. By the way, I think we should ***prepare ourselves to perform this kind of study***. In other words: if the evidence doesn't exist, we must build it. But it requires strong collaborative work. I would like not to talk about which "official" databases we could search for in order to perform the SR first step, because, both reviewers must reach to an agreement on it, and ***it takes part of the SR process***, thus it means that ***must be documented*** at the structured abstract; but these are not the latest news down the square: Cochrane Collaboration has defined strict guidelines on it, all we have to do is to follow them. (I think all this stuff can be arid for some of us, but unfortunately nowadays science may seem -but only seem - a kind of strait jacket. The problem is: we are well intentioned, but how many are not? Think about tobacco industry-sponsored studies during the 1980's, and subscribed by some of the most famous epidemiologists in the world, stating that coffee, and not cigarettes, was the real villain?) Best regards, Luciana. ----- Original Message ----- From: "Tim Cook" To: "FOSS Health" Sent: Tuesday, May 22, 2007 4:11 AM Subject: [FOSS_health] Research Question was:Conference Results > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From tom.jones at tolvenhealth.com Tue May 22 23:35:03 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <003201c79c6e$b1dbb4d0$b406410a@itautecf8e5986> Message-ID: I would not yet give up on the FOSS vs Commercial solution comparisons. I think there is room for a comparison at least in terms of standards adoption/incorporation. Total cost of deployment comparisons will be understandably tricky. I have attached a couple of articles that address hat issue. Tom -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of Luciana Tricai Cavalini Sent: Tuesday, May 22, 2007 5:43 AM To: tw_cook@comcast.net; foss_health@oshca.org Subject: Re: [FOSS_health] Research Question was:Conference Results Hello Tim, Tim and all, I'm sorry if I am being persistent, but I think we should make some effort in order to perform a formal systematic review (SR from now on) after giving up and shift to an expanded review. If we were registered at Cochrane Database (CochDb from now on), our searching for evidence will be safely stored and when the mission is accomplished, we are supposed to be acknowledged by the global scientific community. It is not just a sort of "label": I'm here talking about an empowering strategy which can enrich the results of our efforts. We can be audacious and purpose the inclusion of "black" and "grey" literature in our SR, according to Dr. Churches' suggestion. This is a challenge but it is a good one; I was thinking the same way. Our subject has some specificity that can't be ignored. This can bring some resistance to our CochDb registration but I think it is a good bet and brings relative originality to our project. Dr. Churches raised some methodological issues I was thinking about last night. What is our objective? Search for evidence on FOSS solutions efficacy/efficiency/effectiveness in health compared to what? (1) FOSS x commercial solutions? That's questionable; one can say that we can be only comparing two inefficient interventions. Probably this study should be registered at CochDb only as an econometric study (because the only thing remaining is cost analysis). It is not that bad at all; this is important for decision-makers, and they are obviously our clients. (2) FOSS x no IT intervention? In technical terms, quasi-experimental studies? This is closer to the ideal, but searching for these studies is probably an arid task. I suspect we will find sparse studies designed this way. By the way, I think we should ***prepare ourselves to perform this kind of study***. In other words: if the evidence doesn't exist, we must build it. But it requires strong collaborative work. I would like not to talk about which "official" databases we could search for in order to perform the SR first step, because, both reviewers must reach to an agreement on it, and ***it takes part of the SR process***, thus it means that ***must be documented*** at the structured abstract; but these are not the latest news down the square: Cochrane Collaboration has defined strict guidelines on it, all we have to do is to follow them. (I think all this stuff can be arid for some of us, but unfortunately nowadays science may seem -but only seem - a kind of strait jacket. The problem is: we are well intentioned, but how many are not? Think about tobacco industry-sponsored studies during the 1980's, and subscribed by some of the most famous epidemiologists in the world, stating that coffee, and not cigarettes, was the real villain?) Best regards, Luciana. ----- Original Message ----- From: "Tim Cook" To: "FOSS Health" Sent: Tuesday, May 22, 2007 4:11 AM Subject: [FOSS_health] Research Question was:Conference Results > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health -------------- next part -------------- A non-text attachment was scrubbed... Name: Vista EHR.doc Type: application/msword Size: 45568 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070522/018d58d8/VistaEHR.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Open Source at Midland.doc Type: application/msword Size: 36864 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070522/018d58d8/OpenSourceatMidland.doc From tw_cook at comcast.net Wed May 23 03:04:23 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <1179848401.3545.195.camel@oship> References: <1179848401.3545.195.camel@oship> Message-ID: <1179860663.3545.258.camel@oship> On Tue, 2007-05-22 at 08:35 -0700, Tom Jones wrote: > I would not yet give up on the FOSS vs Commercial solution comparisons. I > think there is room for a comparison at least in terms of standards > adoption/incorporation. There is certainly room for this. However, this type of study is VERY expensive. It would also take several years to accomplish. If you happen to know some one that would fund a 5 - 10 Million USD study then I would love to be involved in it. :-) > Total cost of deployment comparisons will be understandably tricky. I have > attached a couple of articles that address hat issue. > Thanks. Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070522/4bcafa83/attachment.pgp From tw_cook at comcast.net Wed May 23 03:18:47 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <003201c79c6e$b1dbb4d0$b406410a@itautecf8e5986> References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> <1179532880.25453.55.camel@oship> <008a01c79b7c$e8955820$b406410a@itautecf8e5986> <1179734417.27292.45.camel@oship> <1179813816.3545.95.camel@oship> <1179821714.5988.154.camel@tchur-laptop> <1179817871.3545.118.camel@oship> <003201c79c6e$b1dbb4d0$b406410a@itautecf8e5986> Message-ID: <1179861527.3545.272.camel@oship> On Tue, 2007-05-22 at 09:42 -0300, Luciana Tricai Cavalini wrote: > I'm sorry if I am being persistent, but I think we should make some effort > in order to perform a formal systematic review (SR from now on) after giving > up and shift to an expanded review. If we were registered at Cochrane > Database (CochDb from now on), our searching for evidence will be safely > stored and when the mission is accomplished, we are supposed to be > acknowledged by the global scientific community. It is not just a sort of > "label": I'm here talking about an empowering strategy which can enrich the > results of our efforts. In my opinion this is the desired result. We can do research for the knowledge it gives us. But I believe this effort should be geared to withstand scrutiny of the broader scientific community. I think that this is what OSHCA can bring to the FOSS world. This will also likely attract funding for more research. > Dr. Churches raised some methodological issues I was thinking about last > night. What is our objective? Search for evidence on FOSS solutions > efficacy/efficiency/effectiveness in health compared to what? This is a good question. There really is very little actual research on ANY health informatics interventions. I know there is an ongoing project in British Columbia right now that is comparing paper based clinics, EMR acquiring clinics and clinics that are paper based but getting the same change management that an EMR clinic would get. I am looking forward to their results to be published in a year or so. > (1) FOSS x commercial solutions? That's questionable; one can say that we > can be only comparing two inefficient interventions. Probably this study > should be registered at CochDb only as an econometric study (because the > only thing remaining is cost analysis). It is not that bad at all; this is > important for decision-makers, and they are obviously our clients. Cost analysis and change management effects. Because really is it the IT or the increased efficiency due to workflow analysis and change? > (2) FOSS x no IT intervention? In technical terms, quasi-experimental > studies? This is closer to the ideal, but searching for these studies is > probably an arid task. I suspect we will find sparse studies designed this > way. By the way, I think we should ***prepare ourselves to perform this kind > of study***. In other words: if the evidence doesn't exist, we must build > it. But it requires strong collaborative work. I'm not sure what you mean here. I expect that this is the strongest area we will find papers. I do not believe we will find "studies" in any of the categories. > I would like not to talk about which "official" databases we could search > for in order to perform the SR first step, because, both reviewers must > reach to an agreement on it, and ***it takes part of the SR process***, thus > it means that ***must be documented*** at the structured abstract; but these > are not the latest news down the square: Cochrane Collaboration has defined > strict guidelines on it, all we have to do is to follow them. Absolutely. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070522/098bb286/attachment.pgp From tw_cook at comcast.net Wed May 23 03:21:27 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <544364.56736.qm@web30502.mail.mud.yahoo.com> References: <544364.56736.qm@web30502.mail.mud.yahoo.com> Message-ID: <1179861687.3545.276.camel@oship> On Tue, 2007-05-22 at 05:14 -0700, David Chan wrote: > Dr. Tomislav Svoboda, Dr. Alex Jadad, and I have previously submitted a registration application to Cochrane for this title: Review > of Advantages and Disadvantages of Open versus Close Source System Software > in health care related information technology solutions > We haven't started the work formally yet. It seems that if there is sufficient interest in this group, we should collaborate. > > David Hi David, That is a very broad research question. Can you detail your project (metrics, etc.) and maybe how you intend to fund such a project? Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070522/836409ee/attachment.pgp From tchur at it.usyd.edu.au Wed May 23 10:15:04 2007 From: tchur at it.usyd.edu.au (Tim Churches) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <003201c79c6e$b1dbb4d0$b406410a@itautecf8e5986> References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> <1179532880.25453.55.camel@oship> <008a01c79b7c$e8955820$b406410a@itautecf8e5986> <1179734417.27292.45.camel@oship> <1179813816.3545.95.camel@oship> <1179821714.5988.154.camel@tchur-laptop> <1179817871.3545.118.camel@oship> <003201c79c6e$b1dbb4d0$b406410a@itautecf8e5986> Message-ID: <1179886504.5534.24.camel@tchur-laptop> On Tue, 2007-05-22 at 09:42 -0300, Luciana Tricai Cavalini wrote: > Hello Tim, Tim and all, > > I'm sorry if I am being persistent, but I think we should make some effort > in order to perform a formal systematic review (SR from now on) after giving > up and shift to an expanded review. If we were registered at Cochrane > Database (CochDb from now on), our searching for evidence will be safely > stored and when the mission is accomplished, we are supposed to be > acknowledged by the global scientific community. It is not just a sort of > "label": I'm here talking about an empowering strategy which can enrich the > results of our efforts. Yup, that's fine - I'm more familiar with the Cochrane meta-analyses but yes they do publish many qualitative systematic reviews as well. I just wasn't sure to what extent grey literature would be acceptable to the Cochrane people, but as the other Tim points out, there is quite a lot of "semi-formal" open source literature in the form of conference presentations which don't appear in PubMed/MEDLINE but can be found via Google and a few hours of browsing. Also, none of the effort of a formal SR would be wasted if the Cochrane people were not keen on it, or if there was insufficient material - the work could be re-used in an expanded, less formal literature review. > We can be audacious and purpose the inclusion of "black" and "grey" > literature in our SR, according to Dr. Churches' suggestion. This is a > challenge but it is a good one; I was thinking the same way. Our subject has > some specificity that can't be ignored. This can bring some resistance to > our CochDb registration but I think it is a good bet and brings relative > originality to our project. > > Dr. Churches raised some methodological issues I was thinking about last > night. What is our objective? Search for evidence on FOSS solutions > efficacy/efficiency/effectiveness in health compared to what? > > (1) FOSS x commercial solutions? That's questionable; one can say that we > can be only comparing two inefficient interventions. Probably this study > should be registered at CochDb only as an econometric study (because the > only thing remaining is cost analysis). It is not that bad at all; this is > important for decision-makers, and they are obviously our clients. The problem is that costs are very, very rarely mentioned in reports on commercial solutions, either due to commercial-in-confidence and business considerations, or due to embarrassment over the magnitude of the expenditure. I've seen a few open-source reports which mention costs or proxies thereof (such as person-years of effort, as I mentioned in my NetEpi presentation). It should be routine for open-source projects to both keep track of the effort expended by different types of people (even if they are not paid, but increasingly these days they are paid to work on open-source projects), and to report these costs and inputs when they describe the project or application. Often people from the commercial sector are staggered, unbelieving or shocked at how efficient open-source development using open-source tools and light-weight iterative development methodologies can be. > (2) FOSS x no IT intervention? In technical terms, quasi-experimental > studies? This is closer to the ideal, but searching for these studies is > probably an arid task. I suspect we will find sparse studies designed this > way. By the way, I think we should ***prepare ourselves to perform this kind > of study***. In other words: if the evidence doesn't exist, we must build > it. But it requires strong collaborative work. Arid is a lovely but accurate adjective, I suspect. > I would like not to talk about which "official" databases we could search > for in order to perform the SR first step, because, both reviewers must > reach to an agreement on it, and ***it takes part of the SR process***, thus > it means that ***must be documented*** at the structured abstract; but these > are not the latest news down the square: Cochrane Collaboration has defined > strict guidelines on it, all we have to do is to follow them. > > (I think all this stuff can be arid for some of us, but unfortunately > nowadays science may seem -but only seem - a kind of strait jacket. The > problem is: we are well intentioned, but how many are not? Think about > tobacco industry-sponsored studies during the 1980's, and subscribed by some > of the most famous epidemiologists in the world, stating that coffee, and > not cigarettes, was the real villain?) Yes, R.A Fisher (OK, he was a biostatistician) ended his life as an apologist for the tobacco industry. Of course, none of us would be seen dead having anything to do with tobacco products... What you are describing here in the open-source context is the tension between science and politics: open-source is an intensely political activity (even though many of its practitioners do not realise it or disavow it). In those respects, open-source is a lot like public health - and one soon realises, working in public health, that the world of human affairs and politics is not governed or guided by scientific principles - thus compromise is often needed. So, yes, we should endeavour to be scientific, but we are also engaged in advocacy and we should not forget that. Or put another way: let's not forget the political science and political economy of open-source when framing the research questions (and one systematic literature review process can be used to answer multiple research questions, some of which are more rigorous for Cochrane purposes, and others which can be "fluffier" for more socio-political (that is, agitprop) purposes). Tim Ch > ----- Original Message ----- > From: "Tim Cook" > To: "FOSS Health" > Sent: Tuesday, May 22, 2007 4:11 AM > Subject: [FOSS_health] Research Question was:Conference Results > > > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From tchur at it.usyd.edu.au Wed May 23 10:50:36 2007 From: tchur at it.usyd.edu.au (Tim Churches) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <009c01c79c7a$b19f0380$b406410a@itautecf8e5986> References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com> <1179532880.25453.55.camel@oship> <008a01c79b7c$e8955820$b406410a@itautecf8e5986> <1179734417.27292.45.camel@oship> <1179813816.3545.95.camel@oship> <1179821714.5988.154.camel@tchur-laptop> <1179817871.3545.118.camel@oship> <009c01c79c7a$b19f0380$b406410a@itautecf8e5986> Message-ID: <1179888636.5534.53.camel@tchur-laptop> On Tue, 2007-05-22 at 11:08 -0300, Luciana Tricai Cavalini wrote: > Hello Tim, Tim and all, > > If time is a concern, I fear it is possible to put in risk the quality of > the work. Building knowledge is a task which requires reflection and > planning (and some consensus among stakeholders), and ***it takes time***. > Remember our enemies are hegemonic and they will beat us to death if we fail > once. Yes, demonic and hegemonic (but we should refrain from mentioning dialectic imperatives). > Note: conference abstracts ***are supposed to*** enter any SR. OK. > Dr. Churches, I am honored to invite you to be our first reviewer (I would > be the second). Please, feel absolutely free to use all the time you need to > think about it and to say no if it is not at your horizon of interests. What is the proposed timeframe? Something which involves perhaps 1 hour per week between now and the end of the year is feasible, but personally I can't help feeling that my time would be bets spent writing more papers on open-source - that is, creating the literature, not just reviewing it. Tim Ch > ----- Original Message ----- > From: "Tim Cook" > To: "FOSS Health" > Sent: Tuesday, May 22, 2007 4:11 AM > Subject: [FOSS_health] Research Question was:Conference Results > > > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From nandalalx at yahoo.com Wed May 23 09:06:15 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <4765aee0705191659u3833dbd4qbda0d69de8f59806@mail.gmail.com> Message-ID: <557363.66708.qm@web58713.mail.re1.yahoo.com> This is what I presented at the conference! It is indeed easy for physicians to manage the system themselves, with a little effort. I found one who did learn it very fast. However I found that most of the physicians didn't bother to learn and was quite happy to leave it to me to do everything :-( Nandalal --- William F Pearson III wrote: > Just a quick reply. I was unable to attend the > conference by I'm > currently developing a Plone site for my employer. > It will be a portal > for physicians to communicate and a repository for > information about > their various committees. I can vouch for its easy > of management as > well as the ease of use. Feel free to email me if > you have any > questions about it. > > On 5/19/07, Boh Heong Yap wrote: > > hi Tim, Molly and all, > > > > Yes there seems to be a lot of things that such a > "Resource Center" is > > supposed to do/to be. From the discussions so far, > this is what seems to > > be needed (pls correct if I'm wrong) > > > > 1. Resource repository: > > a. presentations from OSHCA 2007 > > a repository for all > presentation/workshop materials from > > the conference for download purposes. > > There should be the possibility for > uploading (one time only, > > unless presenters update their > material) and for downloading > > or viewing on line. > > > > b. FOSS in Health Care: Study Framework > > repositiory for articles, possibly as > links with a short > > description, this could be set up as a > SlashDot type list but > > more well cataloged/categorised and > using a Wiki as a mechanism? > > > > see this as an example: of how > articles can be listed, > > simple and clear > > > > and also enhance it by addding 'tags' > to make it more > > easilly searchable. > > > > also wiki(s) to capture knowledge-base > of the specific sub-areas > > id any. > > > > 2. OSHCA Interoperability project > > - nothing formalised yet here... but it > could be a wiki definition > > of the project, its objectives, scope, > timeline... > > > > - list of intended projects, ie: > > interoperability between SHANA and > NetEPI (for e.g.), etc.. > > > > - list of intended Test-beds for the > individual test beds... > > > > 3. OSHCA Human Resource list > > > > I remember talking briefly to someone at > the conf. about this, > > but can't remember who, so perhaps I can > suggest it here... > > > > We should collect the profiles and > resume's of all OSHCA members, > > (and from what I have seen, its pretty > impressive) this would > > not only give OSHCA great credibility, > but such a list would > > be a great markeing tool/weapon even, > when any of us need to > > present to the likes of government of > private sector. > > Certainly proprietry advocates would > find it hard enuff to > > drum up a similar list. > > > > This is something the big consultants do, > and use to win business, > > we shld do the same.. > > > > ... there are quite a few more we can think > of... > > > > Along with the above.. there are the ususal issues > of access control, > > who can read, write/edit/upload data and so on. > There may also be need > > for creations of groups for individual projects > and the general sysadmin > > of all that, which can be a fair bit of work. > > > > I volunteer to help out with such work, but I > cannot do it alone. As a > > freeelancer, my own projects take priority, as I > do not have the cushion > > of a salary;-) > > > > Also how much resource we can get from OSCC I do > not know. Molly, can > > you initiate a introduction via email and I can > take it from there to > > asses the technical scope/capabilities... > > As Molly mentioned, we will need to upgrade and > install apps., these > > require admin. privilages (or they can allow > sudo/chroot etc..) and OSCC > > may not want to grant us such privilages ... > remains to be seen. Another > > alternative is to just get space from them and use > our own server (HW) > > and we can manage it completely. I can source > unbranded Intel 1U servers > > from about 4k RM, config with Intel MB, 1Gb RAM, > 2x250Gb HD. > > > > Also I do not know Plone, but shld be able to pick > up given time... > > which is always in short supply;-) > > > > We need to discuss this further, and perhaps form > a small team of ppl > > who can do sysadmin work and willing to > contribute. Lets continue > > discussing this... maybe take this off the > mail-list ? > > > > > >The thought that I had on this was that we will > use the OSHCA server. > > >We have agreement from the Open Source Competency > Center to host it (the > > >new OSHCA server) there so it will have better > bandwidth than where it > > >is now. We also need to add a couple of > additional Plone products and > > >upgrade Plone. However, these activities really > require someone on the > > >ground there to download and install these > products. I had intended to > > >address this issue with Boh Heong Yap since he is > in the area (same > > >country at least) and had asked about the Wiki > capability. I also have > > >a query into the OSCC as to their ability to help > in this regard. > > > > > >Certainly we need to relieve Molly of this > burden. She has spent many > > >hours of her own and certainly many pad staff > hours to support this web > > >presence. > > > > > >The parallel issue here is that if we are doing > qualitative analysis > > >then we really need a software package to do > this. I like Atlas.ti but > > >it can be quite expensive. I am looking into the > free CDC application > > >AnSWR but I have yet to be successful getting it > installed and > > >running. > > > > > >Does anyone know of other free / open source > qualitative ananlysis > > >software? > > > > > >Regards, > > >Tim > > > > > > > > > > > > > > > > > >On Sat, 2007-05-19 at 06:17 +0530, Arindam Basu > wrote: > > >> Hi Tim: > > >> > > >> I understand we may require a central > "repository" kind of placeholder > > >> entity, where we can store all our "articles", > "whitepapers", software > > >> or links to software, etc, and all other stuff > that comes to mind > > >> related to this project some way down the > project, if not right away. > > >> Are you planning to set up something like that > already, or does > > >> something already exist specifically for this > project that we can use? > > >> Something like, say a wiki, or an online > database that can be updated > > >> collaboratively by several members? > === message truncated === ____________________________________________________________________________________Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From nandalalx at yahoo.com Wed May 23 09:18:51 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <46506585.8060808@e-cology.ca> Message-ID: <107774.12816.qm@web58715.mail.re1.yahoo.com> Indeed. There are many Products in Plone that are useful. The newest version looks better too. Soon we may have a version of Plone that is stable and working in Zope 3, and that could be really good as Zope 3 has many advatages over zope2, particularly for python developers. Nandalal --- Joseph Dal Molin wrote: > When an updated version of Plone is set up we should > add the Plone > Survey tool... it is a questionnaire building > tool.... > > Joseph > > Arindam Basu wrote: > > Hi Tim and folks: > > > > Although I enjoy working with tikiwiki or MODx > these days, I think Plone > > is a reasonable choice for a collaborative website > -- reasonable but > > somewhat complicated. Plone is also extensible > with python scripting, > > so if we do not like what we see in other software > for our data > > analysis, we are free to write our own stuff! > > > > What I do not like in Plone is its somewhat > dated., ugly look of the > > interface, and the complicated TALs (compared to > that of textpattern or > > wordpress). Then again, the wiki system (Zwiki) is > pretty much built in, > > and throw a blog in it if you will, and you have a > great CMF/CMS to boot. > > > > What are the plans for setting up uniform search > algorithms that people > > can follow to systematize literature retrieval? > Which databases do we > > mine? Also, how about conducting several short > publishable unit based > > lit reviews, as opposed to one, large joint > publication with diverse > > subtopics? > > > > On a completely different note, I tried to > register myself as a paying > > member at the OHSCA site, but was unsuccessful. > What is the procedure to > > pay for memberships? > > > > Kind regards, > > Arin > > > > > > > > Tim Cook wrote: > >> Hi Boh, > >> > >> I will place replies in-line below but I wanted > to let everyone know > >> that some of these issues are taken care of > solutions are in the works > >> already. I hope my comments below help. > >> > >> On Sun, 2007-05-20 at 04:31 +0800, Boh Heong Yap > wrote: > >> > >>> hi Tim, Molly and all, > >>> > >>> Yes there seems to be a lot of things that such > a "Resource Center" is > >>> supposed to do/to be. From the discussions so > far, this is what seems to > >>> be needed (pls correct if I'm wrong) > >>> 1. Resource repository: > >>> a. presentations from OSHCA 2007 > >>> a repository for all > presentation/workshop materials from > >>> the conference for download > purposes. > >>> There should be the possibility for > uploading (one time > >>> only, > >>> unless presenters update their > material) and for > >>> downloading or viewing on line. > >>> > >> > >> The Plone site (Plone is a python based content > management application) > >> is fully able to handle this. You can see that I > have uploaded some of > >> the presentations already. > >> > >> > >> > >> > >>> b. FOSS in Health Care: Study Framework > >>> repositiory for articles, possibly > as links with a short > >>> description, this could be set up as > a SlashDot type list > >>> but more well cataloged/categorised > and using a Wiki as a > >>> mechanism? > >>> > >>> see this as an example: of how > articles can be listed, > >>> simple and clear > >>> > >>> and also enhance it by addding > 'tags' to make it more > >>> easilly searchable. > >>> > >>> also wiki(s) to capture > knowledge-base of the specific > >>> sub-areas > >>> id any. > >>> > >> > >> Actually what we need here is simply a file > repository. *IF** the > >> analysis software will allow us to share a > database then we may store > >> that here as well. But in general I think we > will only be storing > >> source files here and exchange analysis > information in other formats. > >> Again, Plone provides for this out of the box. > The tagging is taken > >> care of because Plone provides for standard > Dublin Core meta-data. one > >> of those meta-data items is a subject or keyword > list. They are part of > >> every object stored in Plone. > >> > >> > >>> 2. OSHCA Interoperability project > >>> - nothing formalised yet here... but > it could be a wiki > >>> definition of the project, its > objectives, scope, > >>> timeline... > >>> - list of intended projects, > ie: > >>> interoperability between SHANA and > NetEPI (for e.g.), etc.. > >>> > >>> - list of intended Test-beds for the > individual test beds... > >>> > >> > >> Could be a Wiki based project I guess. There is > the ZWiki product that > >> I have asked to be installed on the OSHCA server. > It is the same one I > >> installed for the local server at the conference. > >> > >> > >>> 3. OSHCA Human Resource list > >>> I remember talking briefly > to someone at the > >>> conf. about this, > >>> but can't remember who, so perhaps I > can suggest it here... > >>> > >>> We should collect the profiles and > resume's of all OSHCA > >>> members, (and from what I have seen, > its pretty > >>> impressive) this would not only give > OSHCA great > >>> credibility, but such a list would > be a great markeing > >>> tool/weapon even, when any of us need to > present to the > >>> likes of government of private sector. > Certainly > >>> proprietry advocates would find it hard enuff to > drum up > >>> a similar list. > >>> > >> > >> I have requested the registered members list so > that I can add each one > >> to the portal. This would allow for each person > to upload any document > >> they wish to publish and one of the people with > reviewers rights can > >> determine if that document is suitable prior to > it being published on > >> the public website. > >> > >>> This is something the big consultants > do, and use to win > >>> business, we shld do the same.. > >> > >> > >> This is true and as you suggested, could be a > HUGE marketing tool. > >> > >> > >>> ... there are quite a few more we can think > of... > >>> > >>> Along with the above.. there are the ususal > issues === message truncated === ____________________________________________________________________________________Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php From nandalalx at yahoo.com Wed May 23 09:43:23 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <544364.56736.qm@web30502.mail.mud.yahoo.com> Message-ID: <20070523014323.68431.qmail@web58704.mail.re1.yahoo.com> How far have you gone on this? Any literature searches? Nanda --- David Chan wrote: > Dr. Tomislav Svoboda, Dr. Alex Jadad, and I have > previously submitted a registration application to > Cochrane for this title: Review > of Advantages and Disadvantages of Open versus > Close Source System Software > in health care related information technology > solutions > We haven't started the work formally yet. It seems > that if there is sufficient interest in this group, > we should collaborate. > > David > > > David H Chan, MD, CCFP, MSc, FCFP > Associate Professor > Department of Family Medicine > McMaster University > > ----- Original Message ---- > From: Luciana Tricai Cavalini > To: tw_cook@comcast.net; foss_health@oshca.org > Sent: Tuesday, May 22, 2007 8:42:32 AM > Subject: Re: [FOSS_health] Research Question > was:Conference Results > > Hello Tim, Tim and all, > > > > I'm sorry if I am being persistent, but I think we > should make some effort > in order to perform a formal systematic review (SR > from now on) after giving > up and shift to an expanded review. If we were > registered at Cochrane > Database (CochDb from now on), our searching for > evidence will be safely > stored and when the mission is accomplished, we are > supposed to be > acknowledged by the global scientific community. It > is not just a sort of > "label": I'm here talking about an empowering > strategy which can enrich the > results of our efforts. > > We can be audacious and purpose the inclusion of > "black" and "grey" > literature in our SR, according to Dr. Churches' > suggestion. This is a > challenge but it is a good one; I was thinking the > same way. Our subject has > some specificity that can't be ignored. This can > bring some resistance to > our CochDb registration but I think it is a good bet > and brings relative > originality to our project. > > Dr. Churches raised some methodological issues I was > thinking about last > night. What is our objective? Search for evidence on > FOSS solutions > efficacy/efficiency/effectiveness in health compared > to what? > > (1) FOSS x commercial solutions? That's > questionable; one can say that we > can be only comparing two inefficient interventions. > Probably this study > should be registered at CochDb only as an > econometric study (because the > only thing remaining is cost analysis). It is not > that bad at all; this is > important for decision-makers, and they are > obviously our clients. > > (2) FOSS x no IT intervention? In technical terms, > quasi-experimental > studies? This is closer to the ideal, but searching > for these studies is > probably an arid task. I suspect we will find sparse > studies designed this > way. By the way, I think we should ***prepare > ourselves to perform this kind > of study***. In other words: if the evidence doesn't > exist, we must build > it. But it requires strong collaborative work. > > I would like not to talk about which "official" > databases we could search > for in order to perform the SR first step, because, > both reviewers must > reach to an agreement on it, and ***it takes part of > the SR process***, thus > it means that ***must be documented*** at the > structured abstract; but these > are not the latest news down the square: Cochrane > Collaboration has defined > strict guidelines on it, all we have to do is to > follow them. > > > > (I think all this stuff can be arid for some of us, > but unfortunately > nowadays science may seem -but only seem - a kind of > strait jacket. The > problem is: we are well intentioned, but how many > are not? Think about > tobacco industry-sponsored studies during the > 1980's, and subscribed by some > of the most famous epidemiologists in the world, > stating that coffee, and > not cigarettes, was the real villain?) > > > > Best regards, > > > > Luciana. > > > > ----- Original Message ----- > From: "Tim Cook" > To: "FOSS Health" > Sent: Tuesday, May 22, 2007 4:11 AM > Subject: [FOSS_health] Research Question > was:Conference Results > > > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > > > > ____________________________________________________________________________________ > Park yourself in front of a world of choices in > alternative vehicles. Visit the Yahoo! Auto Green > Center. > http://autos.yahoo.com/green_center/ > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ From drcheah at pc.jaring.my Wed May 23 10:09:51 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: [participants] OSHCA 2007 Meeting In-Reply-To: <7C4615229DD21546B2399F446305D82A19DBC2@balrog.mrcad.mrc.ac.za> References: <7C4615229DD21546B2399F446305D82A19DBC2@balrog.mrcad.mrc.ac.za> Message-ID: <4653A26F.7000800@pc.jaring.my> It was good to have a few African participants at OSHCA2007 and to be able to experience KL first time. Thanks for your contribution to the success of the conference. You're probably aware that we have moved follow-up discussions to a new list FOSS_health@oshca.org. Would appreciate if you could subscribe yourself there if you have yet to do so. There are at least 5 main areas for follow-up, otherwise a conference remains a conference: 1. Interoperability issues and data exchange amongst current FOSS applications (thread started by Lee Seldon with volunteers from applications to participate in subsequent test beds), 2. Capacity building in relation with UNU-IGH (myself but I have yet to start the thread) 3. Research Framework (thread started by Tim Cook - I'm not sure if this is related to the cost comparison between proprietary & FOSS deployments or case studies& evidence for FOSS models for support and maintenance ) and 4. Project databases involving enhancement of OSHCA portal to make it suitable for a collaborative network and repository for OSHCA activities (thread yet to be started. Tim Churches). 5. There is one topic under localization and portability to look at low cost hardware solutions and alternative communications (Fouad Bajwa. Thread yet to be started). There were several other topics mentioned like communication ad public relation, funding and support for participants attending OSHCA events, sustainability and revenue models etc but there were no names to champion them yet.... These discussions will continue on different threads at FOSS_health@oshca.org. We hope you can take up a specific area where applications from Africa and Asia will collaborate. It could be under the topics on the data exchange and interoperability. Look forward to your continuing support for OSHCA. Rgds, Molly Chris Seebregts wrote: > Dear Molly and the OSHCA Secretariat > > > > I would like to extend my belated thanks for introducing me to the > OSCHA network and for providing me the opportunity to attend the > wonderful meeting in KL. It was also one of the better and most > useful meetings I have attended and a most enjoyable trip to a great > country. I would also like to thank the IDRC and other sponsors of > the event. I look forward to working on some of the ideas coming out > of the meeting, particularly the interoperability project that was > discussed and put forward again by Lee. > > > > A number of us also enjoyed a very productive visit to the Mampur open > source laboratory in CyberJaya on Saturday and I would like to thank > those who were willing to come in on a holiday to show us around. I > will be presenting some ideas from this meeting to the South African > our ministry of health on Friday. > > > > Kind Regards > > > > Chris Seebregts > > > > > > //===================================================================// > > //Chris Seebregts//__//, PhD// > > //Biomedical Informatics Research Division, Medical Research Council// > > //Graduate Program in Medical Informatics, ////University//__// of > ////KwaZulu-Natal//__//// > > //South Africa//__//// > > //Voice: (mobile): +27 82 461 5556; (office): +27 21 938 0318; > (skype): chris.seebregts// > > //Fax: +27 21 938 0526; Postal: ////PO Box//__// 19070//__//, > Tygerberg 7505, ////South Africa//__ > > //==============================================================================// > > > > > -- > This e-mail and its contents are subject to the > *South African Medical Research Council * > e-mail legal notice available at > http://www.mrc.ac.za/about/EmailLegalNotice.html > > >------------------------------------------------------------------------ > >_______________________________________________ >participants mailing list >participants@oshca.org >http://mailman.oshca.org/mailman/listinfo.cgi/participants > > >------------------------------------------------------------------------ > >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007 2:01 PM > > From drcheah at pc.jaring.my Wed May 23 10:48:43 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA 2007 Meeting] Message-ID: <4653AB8B.80609@pc.jaring.my> -------------- next part -------------- An embedded message was scrubbed... From: "Alvin Marcelo" Subject: Re: [participants] OSHCA 2007 Meeting Date: Wed, 23 May 2007 10:37:51 +0800 Size: 15860 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070523/2d3a13e8/participantsOSHCA2007Meeting.mht From drcheah at pc.jaring.my Wed May 23 11:09:53 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] [Fwd: Re: [participants] OSHCA 2007 Meeting] In-Reply-To: <4653AB8B.80609@pc.jaring.my> References: <4653AB8B.80609@pc.jaring.my> Message-ID: <4653B081.5050203@pc.jaring.my> Molly Cheah wrote: Hi Alvin, The gap analysis is that component bridging the open discussions at the conference and the deployment of participating applications at test beds. The study for IOSN funding for the collaborative framework essentially deals with the preparatory work for testing data exchange (I presume using HL7 v2) and largely theoretical. I was hoping to harness from the discussions here to define outputs and deliverables for the re-submission to IOSN. For some reason, the discussions on interoperability has dwinddled lately. Lee? How about a summary of what was discussed so far. Rgds, Molly > > Hi Molly, > > Where is OSHCA planning to put the 'gaps analysis research' that it > would do for IOSN? > > alvin > > > > On 5/23/07, *Molly Cheah * > wrote: > > It was good to have a few African participants at OSHCA2007 and to be > able to experience KL first time. Thanks for your contribution to the > success of the conference. > > You're probably aware that we have moved follow-up discussions to > a new > list FOSS_health@oshca.org . Would > appreciate if you could subscribe > yourself there if you have yet to do so. > > There are at least 5 main areas for follow-up, otherwise a conference > remains a conference: > > 1. Interoperability issues and data exchange amongst current FOSS > applications (thread started by Lee Seldon with volunteers from > applications to participate in subsequent test beds), > > 2. Capacity building in relation with UNU-IGH (myself but I have > yet to > start the thread) > > 3. Research Framework (thread started by Tim Cook - I'm not sure > if this > is related to the cost comparison between proprietary & FOSS > deployments > or case studies& evidence for FOSS models for support and > maintenance ) and > > 4. Project databases involving enhancement of OSHCA portal to make it > suitable for a collaborative network and repository for OSHCA > activities > (thread yet to be started. Tim Churches). > > 5. There is one topic under localization and portability to look > at low > cost hardware solutions and alternative communications (Fouad Bajwa. > Thread yet to be started). > > There were several other topics mentioned like communication ad public > relation, funding and support for participants attending OSHCA > events, > sustainability and revenue models etc but there were no names to > champion them yet.... > > These discussions will continue on different threads at > FOSS_health@oshca.org . > > We hope you can take up a specific area where applications from Africa > and Asia will collaborate. It could be under the topics on the data > exchange and interoperability. > > Look forward to your continuing support for OSHCA. > > Rgds, > > Molly > Chris Seebregts wrote: > > > Dear Molly and the OSHCA Secretariat > > > > > > > > I would like to extend my belated thanks for introducing me to the > > OSCHA network and for providing me the opportunity to attend the > > wonderful meeting in KL. It was also one of the better and most > > useful meetings I have attended and a most enjoyable trip to a great > > country. I would also like to thank the IDRC and other sponsors of > > the event. I look forward to working on some of the ideas > coming out > > of the meeting, particularly the interoperability project that was > > discussed and put forward again by Lee. > > > > > > > > A number of us also enjoyed a very productive visit to the > Mampur open > > source laboratory in CyberJaya on Saturday and I would like to thank > > those who were willing to come in on a holiday to show us > around. I > > will be presenting some ideas from this meeting to the South African > > our ministry of health on Friday. > > > > > > > > Kind Regards > > > > > > > > Chris Seebregts > > > > > > > > > > > > > //===================================================================// > > > > //Chris Seebregts//__//, PhD// > > > > //Biomedical Informatics Research Division, Medical Research > Council// > > > > //Graduate Program in Medical Informatics, ////University//__// of > > ////KwaZulu-Natal//__//// > > > > //South Africa//__//// > > > > //Voice: (mobile): +27 82 461 5556; (office): +27 21 938 0318; > > (skype): chris.seebregts// > > > > //Fax: +27 21 938 0526; Postal: ////PO Box//__// 19070//__//, > > Tygerberg 7505, ////South Africa//__ > > > > > //==============================================================================// > > > > > > > > > > > -- > > This e-mail and its contents are subject to the > > *South African Medical Research Council * > > e-mail legal notice available at > > http://www.mrc.ac.za/about/EmailLegalNotice.html > > > > > >------------------------------------------------------------------------ > > > > >_______________________________________________ > >participants mailing list > >participants@oshca.org > > http://mailman.oshca.org/mailman/listinfo.cgi/participants > > > > > >------------------------------------------------------------------------ > > > >No virus found in this incoming message. > >Checked by AVG Free Edition. > >Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: > 5/21/2007 2:01 PM > > > > > > _______________________________________________ > participants mailing list > participants@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/participants > > > > > -- > Alvin B. Marcelo, MD > Director > National Telehealth Center > University of the Philippines Manila > Telefax: 632-525-6501 > >------------------------------------------------------------------------ > >_______________________________________________ >participants mailing list >participants@oshca.org >http://mailman.oshca.org/mailman/listinfo.cgi/participants > > >------------------------------------------------------------------------ > >_______________________________________________ >FOSS_health mailing list >FOSS_health@oshca.org >http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > >------------------------------------------------------------------------ > >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.467 / Virus Database: 269.7.6/815 - Release Date: 5/22/2007 3:49 PM > > From tw_cook at comcast.net Wed May 23 15:49:29 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:23 2008 Subject: Capacity Building was: [FOSS_health] Re: [participants] OSHCA 2007 Meeting In-Reply-To: <4653A26F.7000800@pc.jaring.my> References: <7C4615229DD21546B2399F446305D82A19DBC2@balrog.mrcad.mrc.ac.za> <4653A26F.7000800@pc.jaring.my> Message-ID: <1179906569.3545.306.camel@oship> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070523/6de64fff/attachment.pgp From lutricav at vm.uff.br Wed May 23 20:54:28 2007 From: lutricav at vm.uff.br (Luciana Tricai Cavalini) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results References: <544364.56736.qm@web30502.mail.mud.yahoo.com> <1179861687.3545.276.camel@oship> Message-ID: <00e401c79d39$8684df20$b406410a@itautecf8e5986> Dear OSCHA colleagues and friends, Thank you very much for all comments. If we were able to organize all those high-profile reflections, we could probably upload a Working Paper. But now it is time to think about practical questions. SR demands concentrated time and efforts, and please don't think I'm being contradictory regarding my former concern about balancing time and quality. But probably we will need something like 10-20 hours a week for the next 6 months to do things properly. Thus, I think it is better for us to invite Dr. Ganesh to be the first reviewer; I could be the second one. I'll be honored in share this effort with you, Dr. Ganesh. Please, let me know if you agree with it. After this decision-making, I think it is time to fire off the process. I would like to state that Dr. Chan, Dr. Svoboda and Dr. Jadad project is extremely relevant, specially if it possible to define what is the standard benchmark. Best regards, Luciana Tricai Cavalini, MD, PhD Adjunct Professor, Fluminense Federal University, Brazil Visiting Researcher, Karolinska Institutet, Sweden From tw_cook at comcast.net Wed May 23 16:23:50 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <00e401c79d39$8684df20$b406410a@itautecf8e5986> References: <544364.56736.qm@web30502.mail.mud.yahoo.com> <1179861687.3545.276.camel@oship> <00e401c79d39$8684df20$b406410a@itautecf8e5986> Message-ID: <1179908630.3545.313.camel@oship> On Wed, 2007-05-23 at 09:54 -0300, Luciana Tricai Cavalini wrote: > > I would like to state that Dr. Chan, Dr. Svoboda and Dr. Jadad project is > extremely relevant, specially if it possible to define what is the standard > benchmark. I too believe it is relevant but I would like for them to describe in more detail what comparison metric(s) are planned for the open vs. proprietary. Based on my understanding of the title. That study would be a project comparing two or more like systems but based on open vs. proprietary in similar clinical settings. Certainly a worthy study but that isn't what we are doing here. That study will be very resource intensive. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070523/696a8997/attachment.pgp From tw_cook at comcast.net Wed May 23 16:58:00 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:23 2008 Subject: Education was: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <557363.66708.qm@web58713.mail.re1.yahoo.com> References: <557363.66708.qm@web58713.mail.re1.yahoo.com> Message-ID: <1179910680.3545.326.camel@oship> On Tue, 2007-05-22 at 18:06 -0700, Nandalal Gunaratne wrote: > This is what I presented at the conference! It is > indeed easy for physicians to manage the system > themselves, with a little effort. I found one who did > learn it very fast. However I found that most of the > physicians didn't bother to learn and was quite happy > to leave it to me to do everything :-( > > Nandalal As was stated at the conference (by I believe a MAMPU or MoH official) users just want to have it work. They don't want to be involved because the industrialization of the software industry has created this consumer mentality for end users. Probably the biggest hurdle that open source/open content efforts face today is convincing end users that they can and should be part of the process. Even the proprietary software users groups are not overflowing with input from the average user. Where should education start so that we can build trust and cooperation with average end users. First of all we must convince them somehow that a little time spent on feedback, documentation, etc. Will come back to help them in the future. How can we draw on the "Pay It Forward" analogy? http://www.wikihow.com/Pay-It-Forward Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070523/37aea30e/attachment.pgp From jel at wildmedic.org Wed May 23 21:39:23 2007 From: jel at wildmedic.org (Jel Coward) Date: Sun Jan 27 17:55:23 2008 Subject: Education was: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <1179910680.3545.326.camel@oship> References: <557363.66708.qm@web58713.mail.re1.yahoo.com> <1179910680.3545.326.camel@oship> Message-ID: <4654440B.300@wildmedic.org> Tim Cook wrote: > > Probably the biggest hurdle that open source/open content efforts face > today is convincing end users that they can and should be part of the > process. > > Even the proprietary software users groups are not overflowing with > input from the average user. > > Where should education start so that we can build trust and cooperation > with average end users. First of all we must convince them somehow that > a little time spent on feedback, documentation, etc. Will come back to > help them in the future. > > How can we draw on the "Pay It Forward" analogy? > http://www.wikihow.com/Pay-It-Forward > Here in British Columbia we have an active OSCAR user group (an open-source EMR) - many of the end users actively participate - we have our monthly teleconference this morning. Some users don't participate - that is fine too. From first point of contact I emphasise to potential users that they are joining a _community_ and that there is no large, rich company looking after their interests (well, I know, I am not sure that there is with proprietary systems either, those companies look after their shareholders) Regards Jel Coward From nandalalx at yahoo.com Wed May 23 22:34:16 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:23 2008 Subject: Education was: [FOSS_health] Resource Center: for Study Framework etc.. In-Reply-To: <4654440B.300@wildmedic.org> Message-ID: <596684.19568.qm@web58712.mail.re1.yahoo.com> Nice work Jel, I am an end user with a long term experience of giving back to many FOSS projects ( I use FOSS from 1995). I learnt a lot from the FOSS community, for which I thank them wholeheartedly! I have re-written some documentation for some of these projects and helped in many email lists. I have also given feedback, send bug reports and contributed some scriping etc ( I am not a programmer). I have introduced a lot of doctors and nurses to FOSS/ Linux/ Open Office and to non medical people - where a surprising development was the use of OIO as a database application they love ( non-medical use). QUite a few approached me when their systems were ruined by viruses and their MS Access Excel database was lost for good. This is a good opportunity to get in and install a "Powerful Linux System to protect them from viruses and OOo with OIO database server". The ones who did take to FOSS, never stop using it as the system just runs and runs......... :-) Nanda --- Jel Coward wrote: > Tim Cook wrote: > > > > Probably the biggest hurdle that open source/open > content efforts face > > today is convincing end users that they can and > should be part of the > > process. > > > > Even the proprietary software users groups are not > overflowing with > > input from the average user. > > > > Where should education start so that we can build > trust and cooperation > > with average end users. First of all we must > convince them somehow that > > a little time spent on feedback, documentation, > etc. Will come back to > > help them in the future. > > > > How can we draw on the "Pay It Forward" analogy? > > http://www.wikihow.com/Pay-It-Forward > > > > Here in British Columbia we have an active OSCAR > user group (an open-source > EMR) - many of the end users actively participate - > we have our monthly > teleconference this morning. > > Some users don't participate - that is fine too. > > From first point of contact I emphasise to > potential users that they are > joining a _community_ and that there is no large, > rich company looking > after their interests (well, I know, I am not sure > that there is with > proprietary systems either, those companies look > after their shareholders) > > Regards > > Jel Coward > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From nandalalx at yahoo.com Thu May 24 01:26:00 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <1179817871.3545.118.camel@oship> Message-ID: <445671.6292.qm@web58706.mail.re1.yahoo.com> What is the basis for a qualitative study of conference papers? If it is to answer the last mentioned question, we will have to include papers from non foss conferences as well to be fair. In FOSS conferences failures are rarely presented. Indeed it is rare to present failures at conferences, but there can be published papers on failures. What is the criterion "effective?". Even in a qualitative analysis using Grounded Theory, this could be difficult to eventually define. It is subjective, as it begs the question, "effective" for whom? patients/citizens, healthcare workers, administrators/politicians, cost? The analysis will have to answer the following at the end of the Who if any, benefit from healthcare information management? If they do, do they benefit using FOSS? If so how is it effective in doing so? SInce qualitative studies do not create questions or assumptions at the start, it could be a long while before we know where we are going. Qualitative studies are time consuming with sometimes a long period of uncertainty until concepts and categories to propositions evolve, getting all the literature could be expensive ( do we need full articles for the study or do we get only abstracts?), a lot of expertise in this research and use of the data analysis methods and software. When the going gets tough.... :-) Nandalal --- Tim Cook wrote: > Hi Tim, > > Thanks for those very good points. In some ways > though I believe you > may be ahead of where we are (or at least where I > am). > > We haven't formally defined a research question yet > and we also have a > suggestion to maybe break things down into multiple > categories and > produce multiple papers. > > Time is certainly a crucial element. Do we want to > move quickly taking > advantage of momentum? How much time can each > participant contribute? > > So after defining one or more question(s) a schedule > is a good idea, as > Luciana suggested. > > You are likely correct about the black lit. but > there are MANY papers > that have been peer reviewed for conferences. > Informatics is still a > new field and most of the papers are going to be > found in conference > proceedings. As you indicated though most of them > will not be > evaluative or comparative. > > This is why I suggested that we look at doing a > qualitative review of > what is available so that we may make a little sense > of what has been > presented. There are many things that can emerge > out of a good > qualitative study on conference papers. Probably > one of the most > important things would be that one could establish a > basis for funding a > comparative study between open and closed source > implementations. I > personally think that such a study would be > valueless but I am also > aware that many people "need" to see those kinds of > studies. > > > Anyway, my intent in this reply was to offer a > formal research question > suggestion and gather some feedback on it. > > "Is free and open source software effective in > healthcare information > management?" > > Not more so or better than proprietary. Just is it > effective? > > > Thoughts? > > Cheers, > Tim Cook > > > > > On Tue, 2007-05-22 at 16:15 +0800, Tim Churches > wrote: > > On Tue, 2007-05-22 at 02:03 -0400, Tim Cook wrote: > > > On Mon, 2007-05-21 at 08:00 +0000, Tim Cook > wrote: > > > > > > > I have just asked a world wide known expert in > health informatics to be > > > > our second reviewer. As soon as I have a > response to whether this > > > > researcher has the resource available to help > I will let you all know. > > > > > > > > BTW: This researcher is knowledgeable though > not active in the FOSS > > > > community. > > > > > > > > > This researcher does not have time to help with > the study but is willing > > > to review our work. So I am not certain what > was actually needed. > > > Luciana can you elaborate on your email? > > > > I think that Luciana's thorough and principled > approach is admirable, > > but I suggest that a bit of searching on PubMed > and Google is needed > > first (the theoretical risk of bias of the > meta-analysis > > notwithstanding), because I suspect that there is > actually very little > > in the "black literature" (that is, formally > published papers in the > > peer-reviewed biomedical literature) on > open-source in health, and what > > is there is probably descriptive rather than > evaluative or comparative. > > There is a lot more in the "grey literature", > mostly self-published Web > > sites and some non peer-reviewed reports, but > again most will be > > descriptive rather than comparative. However, I > might be wrong, but I > > suggest looking to see how many suitable studies > there are first. If > > there are too few, then perhaps the study question > will need to be > > broadened ie. not just comparison (of some aspects > of) open-source > > versus closed-source health software. > > > > Tim Churches > > > > > > > -- > Timothy Cook, MSc > Health Informatics Research Services > http://home.comcast.net/~tw_cook/ > 01-904-322-8582 > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From dalmolin at e-cology.ca Thu May 24 01:47:53 2007 From: dalmolin at e-cology.ca (Joseph Dal Molin) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <445671.6292.qm@web58706.mail.re1.yahoo.com> References: <445671.6292.qm@web58706.mail.re1.yahoo.com> Message-ID: <46547E49.5030008@e-cology.ca> ...might it be more worthwhile at this stage of evolution for effort be directed to developing a "How To" that FOSS projects could use to publish their work in a way that lends itself more easily for evidence based peer review etc.... Joseph Nandalal Gunaratne wrote: > What is the basis for a qualitative study of > conference papers? If it is to answer the last > mentioned question, we will have to include papers > from non foss conferences as well to be fair. In FOSS > conferences failures are rarely presented. Indeed it > is rare to present failures at conferences, but there > can be published papers on failures. > > What is the criterion "effective?". Even in a > qualitative analysis using Grounded Theory, this could > be difficult to eventually define. It is subjective, > as it begs the question, "effective" for whom? > patients/citizens, healthcare workers, > administrators/politicians, cost? > > The analysis will have to answer the following at the > end of the > > Who if any, benefit from healthcare information > management? If they do, do they benefit using FOSS? If > so how is it effective in doing so? > > SInce qualitative studies do not create questions or > assumptions at the start, it could be a long while > before we know where we are going. > > Qualitative studies are time consuming with sometimes > a long period of uncertainty until concepts and > categories to propositions evolve, getting all the > literature could be expensive ( do we need full > articles for the study or do we get only abstracts?), > a lot of expertise in this research and use of the > data analysis methods and software. > > When the going gets tough.... :-) > > Nandalal > > > > > --- Tim Cook wrote: > >> Hi Tim, >> >> Thanks for those very good points. In some ways >> though I believe you >> may be ahead of where we are (or at least where I >> am). >> >> We haven't formally defined a research question yet >> and we also have a >> suggestion to maybe break things down into multiple >> categories and >> produce multiple papers. >> >> Time is certainly a crucial element. Do we want to >> move quickly taking >> advantage of momentum? How much time can each >> participant contribute? >> >> So after defining one or more question(s) a schedule >> is a good idea, as >> Luciana suggested. >> >> You are likely correct about the black lit. but >> there are MANY papers >> that have been peer reviewed for conferences. >> Informatics is still a >> new field and most of the papers are going to be >> found in conference >> proceedings. As you indicated though most of them >> will not be >> evaluative or comparative. >> >> This is why I suggested that we look at doing a >> qualitative review of >> what is available so that we may make a little sense >> of what has been >> presented. There are many things that can emerge >> out of a good >> qualitative study on conference papers. Probably >> one of the most >> important things would be that one could establish a >> basis for funding a >> comparative study between open and closed source >> implementations. I >> personally think that such a study would be >> valueless but I am also >> aware that many people "need" to see those kinds of >> studies. >> >> >> Anyway, my intent in this reply was to offer a >> formal research question >> suggestion and gather some feedback on it. >> >> "Is free and open source software effective in >> healthcare information >> management?" >> >> Not more so or better than proprietary. Just is it >> effective? >> >> >> Thoughts? >> >> Cheers, >> Tim Cook >> >> >> >> >> On Tue, 2007-05-22 at 16:15 +0800, Tim Churches >> wrote: >>> On Tue, 2007-05-22 at 02:03 -0400, Tim Cook wrote: >>>> On Mon, 2007-05-21 at 08:00 +0000, Tim Cook >> wrote: >>>>> I have just asked a world wide known expert in >> health informatics to be >>>>> our second reviewer. As soon as I have a >> response to whether this >>>>> researcher has the resource available to help >> I will let you all know. >>>>> BTW: This researcher is knowledgeable though >> not active in the FOSS >>>>> community. >>>> >>>> This researcher does not have time to help with >> the study but is willing >>>> to review our work. So I am not certain what >> was actually needed. >>>> Luciana can you elaborate on your email? >>> I think that Luciana's thorough and principled >> approach is admirable, >>> but I suggest that a bit of searching on PubMed >> and Google is needed >>> first (the theoretical risk of bias of the >> meta-analysis >>> notwithstanding), because I suspect that there is >> actually very little >>> in the "black literature" (that is, formally >> published papers in the >>> peer-reviewed biomedical literature) on >> open-source in health, and what >>> is there is probably descriptive rather than >> evaluative or comparative. >>> There is a lot more in the "grey literature", >> mostly self-published Web >>> sites and some non peer-reviewed reports, but >> again most will be >>> descriptive rather than comparative. However, I >> might be wrong, but I >>> suggest looking to see how many suitable studies >> there are first. If >>> there are too few, then perhaps the study question >> will need to be >>> broadened ie. not just comparison (of some aspects >> of) open-source >>> versus closed-source health software. >>> >>> Tim Churches >>> >>> >>> >> -- >> Timothy Cook, MSc >> Health Informatics Research Services >> http://home.comcast.net/~tw_cook/ >> 01-904-322-8582 >>> _______________________________________________ >> FOSS_health mailing list >> FOSS_health@oshca.org >> > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > ____________________________________________________________________________________ > Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. > http://autos.yahoo.com/green_center/ > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > . > From wwilson at umich.edu Thu May 24 03:41:43 2007 From: wwilson at umich.edu (Wayne Wilson) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] [Research Question] In-Reply-To: <4653B081.5050203@pc.jaring.my> References: <4653AB8B.80609@pc.jaring.my> <4653B081.5050203@pc.jaring.my> Message-ID: I am uncertain about the real world effectiveness of a comparison between FOSS software and any commercial system. On the one had it will bring an academic stamp to the FOSS movement, but on the other hand, I don't think academics are the primary decision makers here in the US. I don't know about elsewhere, but I am pretty sure that it's the same in the UK as here. And the the UK care system couldn't be organized more differently than the US care system, yet the decisions about new software are pretty much the same, it's commercial packages. I would focus on positive outcomes from known FOSS projects, especially those that have a strong clinical care worker satisfaction and a demonstrated low cost. The professional budget and IT people can easily make their own cost judgments, so no comparisons are needed. What they need is the clinical staff to start endorsing FOSS clinical software. To do that I think we need to expose every satisfied clinical staff member and start building a following. I think this is what David Chan has done, and I am sure others. We need to get their messages out. In case you have any more time to read, here the way I came up with my suggestions: I work in one of the largest academic health systems in the US. For about 5 years ending just 5 years ago I worked to establish strategic IT directions in clinical care. I had a very difficult time getting any open source software to be 1) accepted by the IT management and 2) gain the support of the academic doctors who were tapped to guide the professional IT shop. Why was this? In the case of IT management, there were several 'buzz' concepts that I couldn't penetrate: 1) We are poor at developing software compared to proprietary software vendor. - now this was cognitive dissonance, since the most successful software ever was an in-house developed clinical web portal. I had set up the web services group, but was not in charge of it after it's creation, I did strategy not implementation. It was a miracle we managed to get a web developer group started at all! I remember sitting at one executive board meeting and presenting data that I had gathered from our commercially procured, competitive economic analysis with other top academic medical centers. That data consistently showed a better accepted system and better return on investment for in-house developed software. That should have caused questions to be raised to be raised about proprietary vendors. Yet, the Nursing representative, who had joint academic and clinical care duties, basically said right after my presentation something like this: "But we know we are no good at developing software, everything we do in house has failed". A bunch of nods at the table and my presentation was promptly forgotten. 2) A re-enforcing factor for the above sentiment - COTS. Commercial Off The Shelf software. It's was the latest word in effective IT management circles. 3) Finally, I discovered that one or more academic doctors had a long term relationship with one or more commercial software companies. This is technically not a conflict of interest, as long as your are not getting directly paid this year by them. But you are free to encourage attendance at love fests like HIMSS, while you hit the booths of your favorites and keep on the lookup for up and coming contenders. 4) Several in house developed software packages had been taken and continue to be taken commercial via start-ups, by either the professional staff or the academic health care staff. The University is pushing licensing of IP revenue to start to make up for the declining support from the public. WE are supposed to be a public institution, yet the public is now more or less a minority investor. Combine that with bubble effect of the wide publicity of all these kids making millions from startups. So, what kind of effort could turn these concepts upside down? I think that COTS and startups have nearly run their course. Things are no better in IT than before those concepts were endorsed. That leaves long term relationships with commercial vendors and the reluctance of professional IT to get involved with FOSS where it counts, in clinical software. It's curious to note that infrastructure FOSS software in professional IT shops can easily come in. It lowers cost and does the job. No other comparisons and factors then count. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070523/064f10c7/PGP.pgp From amidgley2 at defoam.net Tue May 22 06:23:29 2007 From: amidgley2 at defoam.net (Adrian Midgley) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Conference Results In-Reply-To: <1179719963.5988.14.camel@tchur-laptop> References: <200705182350.l4INoAkD029114@svcstsnq08.hotspot.t-mobile.com> <1179719963.5988.14.camel@tchur-laptop> Message-ID: <46521BE1.7050100@defoam.net> Tim Churches wrote: > The Open Source in Health Primer is OK but it unfortunately perpetuates > some myths about open source software. For example, it says: > > We could offer them assistance in producing a second edition, perhaps. -- A From amidgley2 at defoam.net Tue May 22 16:28:43 2007 From: amidgley2 at defoam.net (Dr Adrian Midgley (In the office)) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <003201c79c6e$b1dbb4d0$b406410a@itautecf8e5986> References: <200705182354.l4INs0Gg004150@svcstsnq08.hotspot.t-mobile.com><1179532880.25453.55.camel@oship><008a01c79b7c$e8955820$b406410a@itautecf8e5986><1179734417.27292.45.camel@oship> <1179813816.3545.95.camel@oship><1179821714.5988.154.camel@tchur-laptop> <1179817871.3545.118.camel@oship> <003201c79c6e$b1dbb4d0$b406410a@itautecf8e5986> Message-ID: <4652A9BB.30608@defoam.net> Luciana Tricai Cavalini wrote: Adding rigour is good. It is nice to have a scientist on board, thanks Luciana. -- Adrian Midgley From amidgley2 at defoam.net Tue May 22 16:59:12 2007 From: amidgley2 at defoam.net (Dr Adrian Midgley (In the office)) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] [Fwd: advertisement for OSS Watch Service Manager, deadline 12 noon 25 May 2007] Message-ID: <4652B0E0.5030009@defoam.net> It is a UK job which some of us might know someone who would be useful in and not everyone will have seen. -------------- next part -------------- An embedded message was scrubbed... From: Randy Metcalfe Subject: Reminder: advertisement for OSS Watch Service Manager, deadline 12 noon 25 May 2007 Date: Tue, 22 May 2007 09:36:26 +0100 Size: 5196 Url: http://mailman.oshca.org/pipermail/foss_health/attachments/20070522/402a31b9/advertisementforOSSWatchServiceManagerdeadline12noon25May2007.mht From alvin.marcelo at gmail.com Wed May 23 10:48:05 2007 From: alvin.marcelo at gmail.com (Alvin Marcelo) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] (no subject) Message-ID: <2c9aeb960705221948v1318537dlc9880b1008d28fbc@mail.gmail.com> -- Alvin B. Marcelo, MD Director National Telehealth Center University of the Philippines Manila Telefax: 632-525-6501 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070523/6617f083/attachment.html From lseldon at netspace.net.au Wed May 23 14:59:51 2007 From: lseldon at netspace.net.au (lseldon@netspace.net.au) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <4653A26F.7000800@pc.jaring.my> References: <7C4615229DD21546B2399F446305D82A19DBC2@balrog.mrcad.mrc.ac.za> <4653A26F.7000800@pc.jaring.my> Message-ID: <1179903591.4653e667359df@webmail.netspace.net.au> Interoperability - Message standards Some people seem to be interested in pursuing this. I have had more thoughts since my original proposal. The easiest path would be to go with HL7 v2.X. VistA already supports that - so it could possibly be used as a "test engine". openMRS claims to have implemented HL7 messages, but I am having trouble pinpointing exactly how. I have already pointed to numerous tools for this standard. However, there is a problem. HL7 v2.X is "old technology" and even the standards-makers are moving to XML. Therefore, OSHCA and FOSS should really also move to XML. Note that openMRS uses XML rather extensively. Indeed, any application based on Java, or more specifically J2EE, would almost automatically use XML. A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly easy - just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and openMRS would have to adopt this (in addition to everybody else). Another option would be to use "native" XML and just agree on the terminology (elements). The common terminology would be derived from the mappings of each data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed on. The Java-based applications should not have much difficulty with this, once the data maps are aligned. (I have found that IndivoHealth, which seems to be the engine behind MyOSCAR, has also opted for XML-based data structures not aligned to any single standard.) I am sure somebody can think of other options. It is up to the developers to agree on an option. Lee ------------------------------------------------------------ This email was sent from Netspace Webmail: http://www.netspace.net.au From amidgley2 at defoam.net Thu May 24 06:43:20 2007 From: amidgley2 at defoam.net (Adrian Midgley) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] shadow chancellor commissioned report on FLOSS for Britain Message-ID: <4654C388.50701@defoam.net> http://www.theregister.co.uk/2007/05/04/tory_opensource/ I seem to be on their list. There is a reference to Africa in that Reg article, this relates to the OLPC rather than more general FLOSS adoption. -- Midgley From tom.jones at tolvenhealth.com Thu May 24 07:21:13 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <1179903591.4653e667359df@webmail.netspace.net.au> Message-ID: That depends on what level of interoperability we are discussing. Interoperability has several meanings. For instance, in Lumpkin, John et al "National Committee on Vital and Health Statistics report to the Secretary of the US Department of Health and Human Services on Uniform Data Standards for Patient Medical Record Information" July 6, 2000, p 6, one can find the following: "Interoperability refers to the ability of one computer system to exchange data with another computer system. There are three levels of interoperability. . 'Basic' interoperability allows a message from one computer to be received by another but does not require the ability for the receiving computer to interpret the data. . 'Functional' interoperability is an intermediate level that defines the structure, or format, of messages (hence the term message format standards). Functional interoperability defines the syntax of the message. It ensures that messages between computers can be interpreted at the level of data fields. For example, when one computer has a structured data field for Ear Exam, that computer should be able to pass data from that structured data field on to another computer and have it appropriately stored in a comparably structured field for Ear Exam in the receiving computer. Neither system has understanding, however, of the meaning of the data within the fields. . 'Semantic' interoperability provides common interpretability, i.e., information in the fields within the message can be used in an intelligent manner. At the highest level, semantic interoperability takes advantage of both the structuring of the message and the codification of the data so that the receiving computer can interpret the data." Up through version 2 of the HL7 messaging standard, each enterprise created its own information model. Within the "pipes and bars" (or within the XML standard used by versions 2.4 - 2.n), the representation of the content of each HL7 message was left up to the enterprise (and to the vendors servicing that enterprise's system needs). While each enterprise was able to maintain a degree of interoperability within its boundaries, once an enterprise had to communicate outside of its boundaries, effective communication faltered because the "optionality" inherent in these older versions of HL7 prevented systems from exchanging the meaning of the message content. This shortcoming was highlighted in an NCVHS report to HHS Secretary Shalala in 2000. "Today, these standards have a high degree of optionality in order to accommodate the variability of workflow and availability of information in different care settings. This optionality creates the need for costly and time-consuming customization when implementing message format standards. In addition, vendors and providers have developed their own implementation guides that differ from the standards. Finally, there is little or no conformance testing of message format standards. Non-standard implementations result in the need for costly and time-consuming customization to allow information systems to seamlessly exchange data with one another. These customized solutions contribute to high cost of systems." When enterprises merge for business or regulatory reasons, the need for more robust standards for interoperability becomes more acute. In these merged entities, simple graphic display of numerical laboratory results becomes a nightmare, and automated decision support a virtual impossibility. The situation is just as intolerable for the continuing consolidation of commercial hospital groups as it is for the evolution of government-mandated regional healthcare networks. As the HL7 messaging standards gained wider use (the majority of automated clinical systems take advantage of one or more of the older versions of HL7), recognition of the need to more fully specify and normalize the content of HL7 messages led to the development of the HL7 Reference Information Model (RIM), an integral part of HL7 version 3 (the messaging structure in this version continues the XML standard established with HL7 2.4). In an early white paper, a committee within the HL7 organization proposed a model for the actual content of an HL7 message. They believed "that the proposed model will pave the way to new messaging opportunities, including quality management, outcome assessment, decision support, cost control, and authenticated, accurate, electronic medical record communication". As work on the RIM progressed, one can see that its authors' collective ambition was to represent the world of clinical care in a formal logic that would allow engineers to write code and build clinical information systems that would more accurately represent that world. Such systems could facilitate more effective electronic communication among clinicians, and they could also cross enterprise boundaries and therefore be truly "patient centric". The bottom line, in my view, is that HL7 v2.X sets the bar too low - at functional, rather than semantic, interoperability. HL7 v.3 (which includes the RIM) would be a better level. -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of lseldon@netspace.net.au Sent: Wednesday, May 23, 2007 12:00 AM To: foss_health@oshca.org Subject: [FOSS_health] Re: interoperability Interoperability - Message standards Some people seem to be interested in pursuing this. I have had more thoughts since my original proposal. The easiest path would be to go with HL7 v2.X. VistA already supports that - so it could possibly be used as a "test engine". openMRS claims to have implemented HL7 messages, but I am having trouble pinpointing exactly how. I have already pointed to numerous tools for this standard. However, there is a problem. HL7 v2.X is "old technology" and even the standards-makers are moving to XML. Therefore, OSHCA and FOSS should really also move to XML. Note that openMRS uses XML rather extensively. Indeed, any application based on Java, or more specifically J2EE, would almost automatically use XML. A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly easy - just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and openMRS would have to adopt this (in addition to everybody else). Another option would be to use "native" XML and just agree on the terminology (elements). The common terminology would be derived from the mappings of each data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed on. The Java-based applications should not have much difficulty with this, once the data maps are aligned. (I have found that IndivoHealth, which seems to be the engine behind MyOSCAR, has also opted for XML-based data structures not aligned to any single standard.) I am sure somebody can think of other options. It is up to the developers to agree on an option. Lee ------------------------------------------------------------ This email was sent from Netspace Webmail: http://www.netspace.net.au _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From nandalalx at yahoo.com Thu May 24 09:01:17 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Research Question was:Conference Results In-Reply-To: <46547E49.5030008@e-cology.ca> Message-ID: <143941.64377.qm@web58708.mail.re1.yahoo.com> Joseph, What you suggest is not neccesarily simpler. The internet and FOSS projects are re-defining the evidence based peer review process itself, as to what constitutes good evidence and what makes good peers. Therefore the framework to enable evidence based peer review must be done with this in mind. Looking at the people who participated in OSCHA and those who could not due to various unfortunate reasons, they could be a pretty good peer review group, from many domains and many countries. But the group could be biased as they are having their own projects and favorites and are leaning towards FOSS anyway..... To get the right mix for peer review, we need to get those representing the closed source health apps involved in equal numbers. But will the two groups bother to look at each others apps and literature? Nandalal --- Joseph Dal Molin wrote: > ...might it be more worthwhile at this stage of > evolution for effort be > directed to developing a "How To" that FOSS projects > could use to > publish their work in a way that lends itself more > easily for evidence > based peer review etc.... > > Joseph > > Nandalal Gunaratne wrote: > > What is the basis for a qualitative study of > > conference papers? If it is to answer the last > > mentioned question, we will have to include papers > > from non foss conferences as well to be fair. In > FOSS > > conferences failures are rarely presented. Indeed > it > > is rare to present failures at conferences, but > there > > can be published papers on failures. > > > > What is the criterion "effective?". Even in a > > qualitative analysis using Grounded Theory, this > could > > be difficult to eventually define. It is > subjective, > > as it begs the question, "effective" for whom? > > patients/citizens, healthcare workers, > > administrators/politicians, cost? > > > > The analysis will have to answer the following at > the > > end of the > > > > Who if any, benefit from healthcare information > > management? If they do, do they benefit using > FOSS? If > > so how is it effective in doing so? > > > > SInce qualitative studies do not create questions > or > > assumptions at the start, it could be a long while > > before we know where we are going. > > > > Qualitative studies are time consuming with > sometimes > > a long period of uncertainty until concepts and > > categories to propositions evolve, getting all the > > literature could be expensive ( do we need full > > articles for the study or do we get only > abstracts?), > > a lot of expertise in this research and use of the > > data analysis methods and software. > > > > When the going gets tough.... :-) > > > > Nandalal > > > > > > > > > > --- Tim Cook wrote: > > > >> Hi Tim, > >> > >> Thanks for those very good points. In some ways > >> though I believe you > >> may be ahead of where we are (or at least where I > >> am). > >> > >> We haven't formally defined a research question > yet > >> and we also have a > >> suggestion to maybe break things down into > multiple > >> categories and > >> produce multiple papers. > >> > >> Time is certainly a crucial element. Do we want > to > >> move quickly taking > >> advantage of momentum? How much time can each > >> participant contribute? > >> > >> So after defining one or more question(s) a > schedule > >> is a good idea, as > >> Luciana suggested. > >> > >> You are likely correct about the black lit. but > >> there are MANY papers > >> that have been peer reviewed for conferences. > >> Informatics is still a > >> new field and most of the papers are going to be > >> found in conference > >> proceedings. As you indicated though most of > them > >> will not be > >> evaluative or comparative. > >> > >> This is why I suggested that we look at doing a > >> qualitative review of > >> what is available so that we may make a little > sense > >> of what has been > >> presented. There are many things that can emerge > >> out of a good > >> qualitative study on conference papers. Probably > >> one of the most > >> important things would be that one could > establish a > >> basis for funding a > >> comparative study between open and closed source > >> implementations. I > >> personally think that such a study would be > >> valueless but I am also > >> aware that many people "need" to see those kinds > of > >> studies. > >> > >> > >> Anyway, my intent in this reply was to offer a > >> formal research question > >> suggestion and gather some feedback on it. > >> > >> "Is free and open source software effective in > >> healthcare information > >> management?" > >> > >> Not more so or better than proprietary. Just is > it > >> effective? > >> > >> > >> Thoughts? > >> > >> Cheers, > >> Tim Cook > >> > >> > >> > >> > >> On Tue, 2007-05-22 at 16:15 +0800, Tim Churches > >> wrote: > >>> On Tue, 2007-05-22 at 02:03 -0400, Tim Cook > wrote: > >>>> On Mon, 2007-05-21 at 08:00 +0000, Tim Cook > >> wrote: > >>>>> I have just asked a world wide known expert in > >> health informatics to be > >>>>> our second reviewer. As soon as I have a > >> response to whether this > >>>>> researcher has the resource available to help > >> I will let you all know. > >>>>> BTW: This researcher is knowledgeable though > >> not active in the FOSS > >>>>> community. > >>>> > >>>> This researcher does not have time to help with > >> the study but is willing > >>>> to review our work. So I am not certain what > >> was actually needed. > >>>> Luciana can you elaborate on your email? > >>> I think that Luciana's thorough and principled > >> approach is admirable, > >>> but I suggest that a bit of searching on PubMed > >> and Google is needed > >>> first (the theoretical risk of bias of the > >> meta-analysis > >>> notwithstanding), because I suspect that there > is > >> actually very little > >>> in the "black literature" (that is, formally > >> published papers in the > >>> peer-reviewed biomedical literature) on > >> open-source in health, and what > >>> is there is probably descriptive rather than > >> evaluative or comparative. > >>> There is a lot more in the "grey literature", > >> mostly self-published Web > >>> sites and some non peer-reviewed reports, but > >> again most will be > >>> descriptive rather than comparative. However, I > >> might be wrong, but I > >>> suggest looking to see how many suitable studies > >> there are first. If > >>> there are too few, then perhaps the study > question > >> will need to be > >>> broadened ie. not just comparison (of some > aspects > >> of) open-source > >>> versus closed-source health software. > >>> > >>> Tim Churches > >>> > >>> > >>> > >> -- > >> Timothy Cook, MSc > === message truncated === ____________________________________________________________________________________Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From nandalalx at yahoo.com Thu May 24 09:21:16 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] [Research Question] In-Reply-To: Message-ID: <947113.615.qm@web58713.mail.re1.yahoo.com> Wayne, Thanks for your autobiographical sketch of what happened to your efforts. I have had similar experiences. In developing countries we have the problem of software piracy, which simply nullifies cost, for now! But talks on the need to use legitimate software and that all the software they are using costs more than their computers, only bring gleeful grins and laughter!! Meanwhile the Administrator level looks at companies coming to them with gifts and trips, before deciding who gets the contract and where they procure. Evil lurks here.... :-( I also had the problem that many young IT literate and keen nurses and doctors who were trained by me to use the system, moved from the hospital to others which do not have any network or had a different system. A great blow when they go. Lightening is another problem in Sri Lanka. It has destroyed the network in parts quite a few times, as well as our telephone exchange more recently. I hope it is not choosy between FOSS and closed source software using networks... Perhaps an area of study? Nanda --- Wayne Wilson wrote: > I am uncertain about the real world effectiveness of > a comparison > between FOSS software and any commercial system. > > On the one had it will bring an academic stamp to > the FOSS movement, > but on the other hand, I don't think academics are > the primary > decision makers here in the US. I don't know about > elsewhere, but I > am pretty sure that it's the same in the UK as here. > And the the UK > care system couldn't be organized more differently > than the US care > system, yet the decisions about new software are > pretty much the > same, it's commercial packages. > > I would focus on positive outcomes from known FOSS > projects, > especially those that have a strong clinical care > worker satisfaction > and a demonstrated low cost. The professional > budget and IT people > can easily make their own cost judgments, so no > comparisons are > needed. What they need is the clinical staff to > start endorsing FOSS > clinical software. To do that I think we need to > expose every > satisfied clinical staff member and start building a > following. I > think this is what David Chan has done, and I am > sure others. We > need to get their messages out. > > In case you have any more time to read, here the way > I came up with > my suggestions: > > I work in one of the largest academic health systems > in the US. For > about 5 years ending just 5 years ago I worked to > establish strategic > IT directions in clinical care. > > I had a very difficult time getting any open source > software to be 1) > accepted by the IT management and 2) gain the > support of the > academic doctors who were tapped to guide the > professional IT shop. > > Why was this? > > In the case of IT management, there were several > 'buzz' concepts > that I couldn't penetrate: > > 1) We are poor at developing software compared to > proprietary > software vendor. - now this was cognitive > dissonance, since the most > successful software ever was an in-house developed > clinical web > portal. I had set up the web services group, but > was not in charge > of it after it's creation, I did strategy not > implementation. It was > a miracle we managed to get a web developer group > started at all! I > remember sitting at one executive board meeting and > presenting data > that I had gathered from our commercially procured, > competitive > economic analysis with other top academic medical > centers. That data > consistently showed a better accepted system and > better return on > investment for in-house developed software. That > should have caused > questions to be raised to be raised about > proprietary vendors. Yet, > the Nursing representative, who had joint academic > and clinical care > duties, basically said right after my presentation > something like > this: "But we know we are no good at developing > software, everything > we do in house has failed". A bunch of nods at the > table and my > presentation was promptly forgotten. > > 2) A re-enforcing factor for the above sentiment - > COTS. Commercial > Off The Shelf software. It's was the latest word in > effective IT > management circles. > > 3) Finally, I discovered that one or more academic > doctors had a > long term relationship with one or more commercial > software > companies. This is technically not a conflict of > interest, as long > as your are not getting directly paid this year by > them. But you are > free to encourage attendance at love fests like > HIMSS, while you hit > the booths of your favorites and keep on the lookup > for up and coming > contenders. > > 4) Several in house developed software packages had > been taken and > continue to be taken commercial via start-ups, by > either the > professional staff or the academic health care > staff. The University > is pushing licensing of IP revenue to start to make > up for the > declining support from the public. WE are supposed > to be a public > institution, yet the public is now more or less a > minority investor. > Combine that with bubble effect of the wide > publicity of all these > kids making millions from startups. > > So, what kind of effort could turn these concepts > upside down? I > think that COTS and startups have nearly run their > course. Things > are no better in IT than before those concepts were > endorsed. That > leaves long term relationships with commercial > vendors and the > reluctance of professional IT to get involved with > FOSS where it > counts, in clinical software. It's curious to note > that > infrastructure FOSS software in professional IT > shops can easily > come in. It lowers cost and does the job. No other > comparisons and > factors then count. > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From Klaus at Veil.net.au Thu May 24 13:15:09 2007 From: Klaus at Veil.net.au (Klaus D Veil) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <1179903591.4653e667359df@webmail.netspace.net.au> Message-ID: <00a701c79dc2$80310160$3702a8c0@acerkv> All, The problem has been with " just agree on the terminology (elements)." - this has been in an international agreement process for ~20 years and HL7 SNOMED, LOINC, etc have been the result. Having been involved in healthcare standards development since ~1987, I can only say how very hard it is to develop globally agreed consensus standards... HL7 V2.x comes in a compact delimited version ("vertical bars") or in a XML version (It is actually not a XML wrapper, but true XML). V3 is very complex and requires extensive knowledge of the HL7 model ("RIM") and is quite resource intensive (both implementation and run-time) to implement. Fortunately, there are a number of initiatives underway to simplify its use. For those who recently joined this list, here is an HL7 Intro: www.HL7.com.au/FAQ.htm For those looking for HL7 tools and resources, go to: www.HL7.org.au/HL7-Tools.htm There is also a RSS feed at www.HL7.org.au/HL7-Tools-RSS.xml Klaus ?????HL7 Australia ___________________________________________ PO Box 3289,? WESTON CREEK 2611,? Australia Phone: +61 412 746 457 ?? ??Fax:? +61 2 9475 0685 E-mail: Chair@HL7.org.au?? Web: www.HL7.org.au ____________________________________________ -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of lseldon@netspace.net.au Sent: Wednesday, 23 May 2007 17:00 To: foss_health@oshca.org Subject: [FOSS_health] Re: interoperability Interoperability - Message standards Some people seem to be interested in pursuing this. I have had more thoughts since my original proposal. The easiest path would be to go with HL7 v2.X. VistA already supports that - so it could possibly be used as a "test engine". openMRS claims to have implemented HL7 messages, but I am having trouble pinpointing exactly how. I have already pointed to numerous tools for this standard. However, there is a problem. HL7 v2.X is "old technology" and even the standards-makers are moving to XML. Therefore, OSHCA and FOSS should really also move to XML. Note that openMRS uses XML rather extensively. Indeed, any application based on Java, or more specifically J2EE, would almost automatically use XML. A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly easy - just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and openMRS would have to adopt this (in addition to everybody else). Another option would be to use "native" XML and just agree on the terminology (elements). The common terminology would be derived from the mappings of each data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed on. The Java-based applications should not have much difficulty with this, once the data maps are aligned. (I have found that IndivoHealth, which seems to be the engine behind MyOSCAR, has also opted for XML-based data structures not aligned to any single standard.) I am sure somebody can think of other options. It is up to the developers to agree on an option. Lee ------------------------------------------------------------ This email was sent from Netspace Webmail: http://www.netspace.net.au _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From bhyz at mac.com Thu May 24 15:05:18 2007 From: bhyz at mac.com (Boh Heong Yap) Date: Sun Jan 27 17:55:23 2008 Subject: Re(2): [FOSS_health] Re: interoperability In-Reply-To: <200705232321.l4NNLboL001846@mac.com> References: <1179903591.4653e667359df@webmail.netspace.net.au> <200705232321.l4NNLboL001846@mac.com> Message-ID: <20070524070518.32367@smtp.mac.com> tom, you brought up some good points here, what I like is the last part "...once an enterprise had to communicate outside of its boundaries, effective communication faltered because the "optionality" inherent in these older versions of HL7 prevented systems from exchanging the meaning of the message content." This is exactly what is happening here in Malaysia, where the government (Ministry of Healt/MOH) has invested in different proprietry system which claim HL7 compatibility, but cannot interoperate! Can you make that report you mention available to OSHCA members? a PDF would be good. >That depends on what level of interoperability we are discussing. >Interoperability has several meanings. For instance, in Lumpkin, John et al >"National Committee on Vital and Health Statistics report to the Secretary >of the US Department of Health and Human Services on Uniform Data Standards >for Patient Medical Record Information" July 6, 2000, p 6, one can find the >following: > >"Interoperability refers to the ability of one computer system to exchange >data with another computer system. There are three levels of >interoperability. >. 'Basic' interoperability allows a message from one computer to be >received by another but does not require the ability for the receiving >computer to interpret the data. >. 'Functional' interoperability is an intermediate level that defines >the structure, or format, of messages (hence the term message format >standards). Functional interoperability defines the syntax of the message. >It ensures that messages between computers can be interpreted at the level >of data fields. For example, when one computer has a structured data field >for Ear Exam, that computer should be able to pass data from that structured >data field on to another computer and have it appropriately stored in a >comparably structured field for Ear Exam in the receiving computer. Neither >system has understanding, however, of the meaning of the data within the >fields. >. 'Semantic' interoperability provides common interpretability, i.e., >information in the fields within the message can be used in an intelligent >manner. At the highest level, semantic interoperability takes advantage of >both the structuring of the message and the codification of the data so that >the receiving computer can interpret the data." > >Up through version 2 of the HL7 messaging standard, each enterprise created >its own information model. Within the "pipes and bars" (or within the XML >standard used by versions 2.4 - 2.n), the representation of the content of >each HL7 message was left up to the enterprise (and to the vendors servicing >that enterprise's system needs). While each enterprise was able to maintain >a degree of interoperability within its boundaries, once an enterprise had >to communicate outside of its boundaries, effective communication faltered >because the "optionality" inherent in these older versions of HL7 prevented >systems from exchanging the meaning of the message content. This shortcoming >was highlighted in an NCVHS report to HHS Secretary Shalala in 2000. > >"Today, these standards have a high degree of optionality in order to >accommodate the variability of workflow and availability of information in >different care settings. This optionality creates the need for costly and >time-consuming customization when implementing message format standards. In >addition, vendors and providers have developed their own implementation >guides that differ from the standards. Finally, there is little or no >conformance testing of message format standards. > >Non-standard implementations result in the need for costly and >time-consuming customization to allow information systems to seamlessly >exchange data with one another. These customized solutions contribute to >high cost of systems." > >When enterprises merge for business or regulatory reasons, the need for more >robust standards for interoperability becomes more acute. In these merged >entities, simple graphic display of numerical laboratory results becomes a >nightmare, and automated decision support a virtual impossibility. The >situation is just as intolerable for the continuing consolidation of >commercial hospital groups as it is for the evolution of government-mandated >regional healthcare networks. > >As the HL7 messaging standards gained wider use (the majority of automated >clinical systems take advantage of one or more of the older versions of >HL7), recognition of the need to more fully specify and normalize the >content of HL7 messages led to the development of the HL7 Reference >Information Model (RIM), an integral part of HL7 version 3 (the messaging >structure in this version continues the XML standard established with HL7 >2.4). In an early white paper, a committee within the HL7 organization >proposed a model for the actual content of an HL7 message. They believed >"that the proposed model will pave the way to new messaging opportunities, >including quality management, outcome assessment, decision support, cost >control, and authenticated, accurate, electronic medical record >communication". As work on the RIM progressed, one can see that its authors' >collective ambition was to represent the world of clinical care in a formal >logic that would allow engineers to write code and build clinical >information systems that would more accurately represent that world. Such >systems could facilitate more effective electronic communication among >clinicians, and they could also cross enterprise boundaries and therefore be >truly "patient centric". > >The bottom line, in my view, is that HL7 v2.X sets the bar too low - at >functional, rather than semantic, interoperability. HL7 v.3 (which includes >the RIM) would be a better level. > > > >-----Original Message----- >From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] >On Behalf Of lseldon@netspace.net.au >Sent: Wednesday, May 23, 2007 12:00 AM >To: foss_health@oshca.org >Subject: [FOSS_health] Re: interoperability > >Interoperability - Message standards > >Some people seem to be interested in pursuing this. >I have had more thoughts since my original proposal. > >The easiest path would be to go with HL7 v2.X. VistA already supports that - >so >it could possibly be used as a "test engine". openMRS claims to have >implemented >HL7 messages, but I am having trouble pinpointing exactly how. I have >already >pointed to numerous tools for this standard. > >However, there is a problem. HL7 v2.X is "old technology" and even the >standards-makers are moving to XML. Therefore, OSHCA and FOSS should really >also >move to XML. >Note that openMRS uses XML rather extensively. Indeed, any application based >on >Java, or more specifically J2EE, would almost automatically use XML. > >A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly easy >- >just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and >openMRS would have to adopt this (in addition to everybody else). > >Another option would be to use "native" XML and just agree on the >terminology >(elements). The common terminology would be derived from the mappings of >each >data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed >on. >The Java-based applications should not have much difficulty with this, once >the >data maps are aligned. (I have found that IndivoHealth, which seems to be >the >engine behind MyOSCAR, has also opted for XML-based data structures not >aligned >to any single standard.) > >I am sure somebody can think of other options. >It is up to the developers to agree on an option. >Lee > > > regards, -- Boh Heong, Yap email: bhyz@mac.com From bhyz at mac.com Thu May 24 15:05:33 2007 From: bhyz at mac.com (Boh Heong Yap) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <1179903591.4653e667359df@webmail.netspace.net.au> References: <7C4615229DD21546B2399F446305D82A19DBC2@balrog.mrcad.mrc.ac.za> <4653A26F.7000800@pc.jaring.my> <1179903591.4653e667359df@webmail.netspace.net.au> Message-ID: <20070524070533.14776@smtp.mac.com> hi all, my 3 cents worth ;-) agreed, with Lee, we should go with the later XML based stds. to 'future proof' the stuff we do. Also as Lee pointed out, most languages, certainly Java and Python has strong support for XML handling. Also as a suggestion, why don't we pick just ONE aspect of interoperability to work on; and the OBVIOUS one would be EHR/patient records' (or a subset of?), say the demographic details - then expand that to encompass diagnosis and prescription (which I understand may encompass other encoding standards (ICD, SNOMED etc...) Also as a methodology and to spread the knowledge/work around, (for e.g. I can hack code and handle complex data-structures, but have next to zero knowledge of HL7 et-al, whereas others have the HL7 knowhow) can someone with the knowhow specify/extract the encoding (representation of EHR, Electornic Health Records, in XML) so that other hackers can then work at building the 'black-boxes' the do the translation. Perhaps this is best illustrated by a simple diagram: 1. 5. +--------+ 2. 4. +-----------+ | app.1 | +------+ 3. +-------+ | app.2 | |OpenMRS |<-->|black | +---------------+ |black |<-->|VistA | +--------+ | box |<-->| HL7/XML rep. |<-->| box | | | +------+ | of EHR | +-------+ +-----------+ +---------------+ When one app needs to talk to another app. to transfer EHR, its done thru the intermediary of the HL7 representation of a EHR, which might be a bunch of XML tagged data, show as 3. in the diagram. OpenMRS may have its own internal representation, and so does VistA. What is needed are the 2 'black-boxes' represented by 2. & 4. above. What these are, is code that can read/write from their internal representation to the HL7 representation. Once 3. is specified (among OSHCA devlopers) any other app. that needs to trnsfer EHR would just need to build its own 'black-box'. e.g SAHANA would build a 'SAHANA black-box' to join the party... And if written well, the 'black-boxes' can be done as libraries for specific languages (say a Java, PHP, Python vesions...) to that it can be reused by other apps. comments? PS I may not be able to post as often as I like, as my Lab project workload is increasing, but will be readig this list... >Interoperability - Message standards > >Some people seem to be interested in pursuing this. >I have had more thoughts since my original proposal. > >The easiest path would be to go with HL7 v2.X. VistA already supports >that - so >it could possibly be used as a "test engine". openMRS claims to have >implemented >HL7 messages, but I am having trouble pinpointing exactly how. I have already >pointed to numerous tools for this standard. > >However, there is a problem. HL7 v2.X is "old technology" and even the >standards-makers are moving to XML. Therefore, OSHCA and FOSS should >really also >move to XML. >Note that openMRS uses XML rather extensively. Indeed, any application >based on >Java, or more specifically J2EE, would almost automatically use XML. > >A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly easy - >just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and >openMRS would have to adopt this (in addition to everybody else). > >Another option would be to use "native" XML and just agree on the terminology >(elements). The common terminology would be derived from the mappings of each >data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed on. >The Java-based applications should not have much difficulty with this, >once the >data maps are aligned. (I have found that IndivoHealth, which seems to be the >engine behind MyOSCAR, has also opted for XML-based data structures not >aligned >to any single standard.) > >I am sure somebody can think of other options. >It is up to the developers to agree on an option. >Lee > > > >------------------------------------------------------------ >This email was sent from Netspace Webmail: http://www.netspace.net.au > >_______________________________________________ >FOSS_health mailing list >FOSS_health@oshca.org >http://mailman.oshca.org/mailman/listinfo.cgi/foss_healt regds. boh From tchur at it.usyd.edu.au Thu May 24 15:58:06 2007 From: tchur at it.usyd.edu.au (Tim Churches) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability Message-ID: <1179993486.5854.88.camel@tchur-laptop> On Wed, 2007-05-23 at 16:21 -0700, Tom Jones wrote: > That depends on what level of interoperability we are discussing. > Interoperability has several meanings. For instance, in Lumpkin, John et al > "National Committee on Vital and Health Statistics report to the Secretary > of the US Department of Health and Human Services on Uniform Data Standards > for Patient Medical Record Information" July 6, 2000, p 6, one can find the > following: > > "Interoperability refers to the ability of one computer system to exchange > data with another computer system. There are three levels of > interoperability. > . 'Basic' interoperability allows a message from one computer to be > received by another but does not require the ability for the receiving > computer to interpret the data. > . 'Functional' interoperability is an intermediate level that defines > the structure, or format, of messages (hence the term message format > standards). Functional interoperability defines the syntax of the message. > It ensures that messages between computers can be interpreted at the level > of data fields. For example, when one computer has a structured data field > for Ear Exam, that computer should be able to pass data from that structured > data field on to another computer and have it appropriately stored in a > comparably structured field for Ear Exam in the receiving computer. Neither > system has understanding, however, of the meaning of the data within the > fields. > . 'Semantic' interoperability provides common interpretability, i.e., > information in the fields within the message can be used in an intelligent > manner. At the highest level, semantic interoperability takes advantage of > both the structuring of the message and the codification of the data so that > the receiving computer can interpret the data." > > Up through version 2 of the HL7 messaging standard, each enterprise created > its own information model. Within the "pipes and bars" (or within the XML > standard used by versions 2.4 - 2.n), the representation of the content of > each HL7 message was left up to the enterprise (and to the vendors servicing > that enterprise's system needs). While each enterprise was able to maintain > a degree of interoperability within its boundaries, once an enterprise had > to communicate outside of its boundaries, effective communication faltered > because the "optionality" inherent in these older versions of HL7 prevented > systems from exchanging the meaning of the message content. This shortcoming > was highlighted in an NCVHS report to HHS Secretary Shalala in 2000. > > "Today, these standards have a high degree of optionality in order to > accommodate the variability of workflow and availability of information in > different care settings. This optionality creates the need for costly and > time-consuming customization when implementing message format standards. In > addition, vendors and providers have developed their own implementation > guides that differ from the standards. Finally, there is little or no > conformance testing of message format standards. > > Non-standard implementations result in the need for costly and > time-consuming customization to allow information systems to seamlessly > exchange data with one another. These customized solutions contribute to > high cost of systems." > > When enterprises merge for business or regulatory reasons, the need for more > robust standards for interoperability becomes more acute. In these merged > entities, simple graphic display of numerical laboratory results becomes a > nightmare, and automated decision support a virtual impossibility. The > situation is just as intolerable for the continuing consolidation of > commercial hospital groups as it is for the evolution of government-mandated > regional healthcare networks. > > As the HL7 messaging standards gained wider use (the majority of automated > clinical systems take advantage of one or more of the older versions of > HL7), recognition of the need to more fully specify and normalize the > content of HL7 messages led to the development of the HL7 Reference > Information Model (RIM), an integral part of HL7 version 3 (the messaging > structure in this version continues the XML standard established with HL7 > 2.4). In an early white paper, a committee within the HL7 organization > proposed a model for the actual content of an HL7 message. They believed > "that the proposed model will pave the way to new messaging opportunities, > including quality management, outcome assessment, decision support, cost > control, and authenticated, accurate, electronic medical record > communication". As work on the RIM progressed, one can see that its authors' > collective ambition was to represent the world of clinical care in a formal > logic that would allow engineers to write code and build clinical > information systems that would more accurately represent that world. Such > systems could facilitate more effective electronic communication among > clinicians, and they could also cross enterprise boundaries and therefore be > truly "patient centric". > > The bottom line, in my view, is that HL7 v2.X sets the bar too low - at > functional, rather than semantic, interoperability. HL7 v.3 (which includes > the RIM) would be a better level. I think that is a rather good summary of the problems with HL7 v2.x. I would add that the HL7 specifications do not really address the issue of what receiving information systems are supposed to with the the messages which they are sent. For example, if a pathology laboratory discovers a life threatening abnormal result, say a very low serum potassium level, then it can send an HL7 result message to the requesting doctor's system, and it can even flag in that message that the result is abnormal and urgent and life-threatening, but HL7 provides no mechanism for directly requesting that the other system bring this result to the attention of a relevant human being (probably a doctor or nurse), nor does HL7 provide any help with communicating back that the requested action was done, or was not done as the case may be. In other words, HL7 v2.x defines (rather loosely in most cases) how data or information should be formatted and to a lesser or non-existent extent how data should be semantically represented, but is completely silent about what should be done with that data by the receiving computer system: actions are all implicit and have to be worked out on a case-by-case basis. What is actually needed is a mechanism for receiving systems to advertise what actions they are able or willing to perform, and a mechanism to explicitly request one or more of those actions when sending data to that system. In order words, a remote procedure calling system. CORBA and CORBAmed had all this a decade or more ago, but HL7 won out over CORBAmed for various reasons. Thus, apart from solving all the problems with the optionality of the HL7 v2.x specifications and the many semantic encoding issues which HL7 v2.x does not address, there is also the problem of negotiating what receiving systems are supposed to do with the HL7 messages which they receive, and that ends up being implicit and again worked out on a case-by-case basis. Now, none of these issues mean that one should not use HL7 v2.x, just that one needs to be aware that the decision to use HL7 v2.x is only a very partial solution to the interoperability problem, and that in almost all cases, a lot more work will be needed to either define additional (usually national, regional or local) standards and protocols layered on top of HL7 v2.x for specific purposes (eg path lab results reporting), or a lot of case-by-case, point-to-point negotiation and pre-processing and post-processing of HL7 messages will be needed in order to achieve useful levels of interoperability. That's why I opined at the OSHCA conference that the decision to use HL7 v2.x in any interoperability circumstance should be a considered one, not an automatic one, and that HL7 is not a panacea, and in some cases it may be better to use a simpler, more light-weight mechanisms to exchange data between health applications. Perhaps openEHR and/or HL7 v3.x will solve these problems, but as various people have said, practical implementations of these are still some way off and we need to get on with life (and death) in the meantime. The other point regarding HL7 is that its whole interoperability model is based on the assumption that health care applications are black boxes and that their internal data models and data representations can't be examined, modified or augmented - hence the need for a single comprehensive standard (which is supposed to be HL7). Of course, that model is valid for almost all closed-source software, but it is not true of open-source health software. When considering interoperability of open-source information systems, other models are possible. Underlying databases and data stores can often be accessed directly, it may be possible to actually embed one open-source application in another, or special-purpose data interchange modules can be written. For example, say I want SAHANA to exchange data with NetEpi. The traditional approach is to look at the HL7 specifications, work out which message types and message segments are most appropriate, and for the developers of each of the applications to add the ability to emit and consume HL7 messages which are compliant with the relevant aspects and parts of the HL7 specification. Of course, the actually data items collected by SAHANA and NetEpi are quite volatile and dynamic (that is, the data which needs to be exchanged will change as a disaster or a disease outbreak develops and unfolds), and HL7 v2.x does not handle changing data requirements very nicely at all. But alternative approaches are possible. For example, as a NetEpi developer, I can download all the SAHANA source code, set up an instance of it, and write a plug-in module or code patch for SAHANA which will produce data in exactly the form that NetEpi requires - without all the overhead of pouring through 700 pages of HL7 v2.x specifications, then having to augment those specifications in any case, write up those augmented specifications, send them tot he SAHAN people and try to get them to implement them. Or I can write a NetEpi extension to directly access the underlying SAHANA database. Or both SAHANA and NetEpi can agree to use XML-RPC or some other simple mechanism to interchange data and to remotely cause specific actions to occur in each others' systems. Of course, the objection will be raised that it will take more resources to define and create such special-purpose interfaces than it would to use a "standard" HL7 interface. The problem is, as has been discussed, that HL7 v2.x is an insufficient standard in so many respects, and thus it may, in many circumstances, be harder and more resource intensive, even in the long-term, to use it than to ignore it. Also, health applications and information systems themselves are in a constant state of development and change (particularly open-source applications), and so ongoing maintenance of any interoperability mechanism, whether it involves HL7 or not, will be needed in any case. Finally, open-source health information systems, particularly those deployed in developing and transitional countries and those deployed in community settings as opposed to hospitals and large clinics, should not allow themselves to be dictated to by a "standard" which is primarily designed to help run large hospitals in rich countries. After all, there is not exactly a lot of evidence from rich countries that have adopted HL7 v2.x widely that it is a better solution than other approaches. There are so many stories of systems which are supposedly "HL7" compliant failing to interoperate properly, or only being able to interoperate after a lot of case-by-case and point-to-point effort and money is expended. Open-source health systems should only use what has been demonstrated to work well, and should feel free to explore alternatives to HL7. Remember, what matters is that patient care and public health is improved, not that systems are compliant with arbitrary information standards developed in rich countries to run their well-resourced hospitals. Let's not put the cart before the horse. OK, having said all that, what would be really fascinating is one or more case studies in which interoperability between two or more open-source health information systems was implemented using a traditional, HL7 v2.x approach, and in parallel was implemented using a more ad hoc, light-weight approach (or approaches). Costs, time, ease of implementation and reliability and utility of the resulting interoperability could be compared. Finally, I should add that in my work in public health surveillance, we do use HL7 v2.x. That is why I am aware of the issues I have outlined above. In developed countries like Australia, there is little choice but to use HL7 v2.x. But in other settings where financial resources for health care are far less, please do consider alternatives, even if they are only temporary while waiting for HL7 v3.x and openEHR to be finished and become easy to use and well-supported. Tim C > -----Original Message----- > From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] > On Behalf Of lseldon@netspace.net.au > Sent: Wednesday, May 23, 2007 12:00 AM > To: foss_health@oshca.org > Subject: [FOSS_health] Re: interoperability > > Interoperability - Message standards > > Some people seem to be interested in pursuing this. > I have had more thoughts since my original proposal. > > The easiest path would be to go with HL7 v2.X. VistA already supports that - > so > it could possibly be used as a "test engine". openMRS claims to have > implemented > HL7 messages, but I am having trouble pinpointing exactly how. I have > already > pointed to numerous tools for this standard. > > However, there is a problem. HL7 v2.X is "old technology" and even the > standards-makers are moving to XML. Therefore, OSHCA and FOSS should really > also > move to XML. > Note that openMRS uses XML rather extensively. Indeed, any application based > on > Java, or more specifically J2EE, would almost automatically use XML. > > A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly easy > - > just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and > openMRS would have to adopt this (in addition to everybody else). > > Another option would be to use "native" XML and just agree on the > terminology > (elements). The common terminology would be derived from the mappings of > each > data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed > on. > The Java-based applications should not have much difficulty with this, once > the > data maps are aligned. (I have found that IndivoHealth, which seems to be > the > engine behind MyOSCAR, has also opted for XML-based data structures not > aligned > to any single standard.) > > I am sure somebody can think of other options. > It is up to the developers to agree on an option. > Lee > > > > ------------------------------------------------------------ > This email was sent from Netspace Webmail: http://www.netspace.net.au > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From nandalalx at yahoo.com Thu May 24 22:07:42 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <20070524070533.14776@smtp.mac.com> Message-ID: <315903.26370.qm@web58715.mail.re1.yahoo.com> Worth every cent Boh! However we should think long and hard when we choose the two apps that should interoperate. They must be built on languages that are familiar to most, ideally java or python. OpenMRS is a Java/Tomcat based app and is a good example. OSCAR Canada is the other using the same. This will make things simpler and ensure most can take part and understand the coding and source much much better. Nandalal --- Boh Heong Yap wrote: > hi all, > > my 3 cents worth ;-) > > agreed, with Lee, we should go with the later XML > based stds. to 'future > proof' the stuff we do. Also as Lee pointed out, > most languages, > certainly Java and Python has strong support for XML > handling. > > Also as a suggestion, why don't we pick just ONE > aspect of > interoperability to work on; and the OBVIOUS one > would be EHR/patient > records' (or a subset of?), say the demographic > details - then expand > that to encompass diagnosis and prescription (which > I understand may > encompass other encoding standards (ICD, SNOMED > etc...) > > Also as a methodology and to spread the > knowledge/work around, > (for e.g. I can hack code and handle complex > data-structures, but have > next to zero knowledge of HL7 et-al, whereas others > have the HL7 knowhow) > can someone with the knowhow specify/extract the > encoding > (representation of EHR, Electornic Health Records, > in XML) so that other > hackers can then work at building the 'black-boxes' > the do the > translation. Perhaps this is best illustrated by a > simple diagram: > > 1. > 5. > +--------+ 2. 4. > +-----------+ > | app.1 | +------+ 3. > +-------+ | app.2 | > |OpenMRS |<-->|black | +---------------+ > |black |<-->|VistA | > +--------+ | box |<-->| HL7/XML rep. |<-->| box > | | | > +------+ | of EHR | > +-------+ +-----------+ > +---------------+ > > When one app needs to talk to another app. to > transfer EHR, its done > thru the intermediary of the HL7 representation of a > EHR, which might be > a bunch of XML tagged data, show as 3. in the > diagram. > > OpenMRS may have its own internal representation, > and so does VistA. > What is needed are the 2 'black-boxes' represented > by 2. & 4. above. > What these are, is code that can read/write from > their internal > representation to the HL7 representation. > > Once 3. is specified (among OSHCA devlopers) any > other app. that needs > to trnsfer EHR would just need to build its own > 'black-box'. e.g SAHANA > would build a 'SAHANA black-box' to join the > party... > > And if written well, the 'black-boxes' can be done > as libraries for > specific languages (say a Java, PHP, Python > vesions...) to that it can > be reused by other apps. > > comments? > > PS I may not be able to post as often as I like, as > my Lab project > workload is increasing, but will be readig this > list... > > >Interoperability - Message standards > > > >Some people seem to be interested in pursuing this. > >I have had more thoughts since my original > proposal. > > > >The easiest path would be to go with HL7 v2.X. > VistA already supports > >that - so > >it could possibly be used as a "test engine". > openMRS claims to have > >implemented > >HL7 messages, but I am having trouble pinpointing > exactly how. I have already > >pointed to numerous tools for this standard. > > > >However, there is a problem. HL7 v2.X is "old > technology" and even the > >standards-makers are moving to XML. Therefore, > OSHCA and FOSS should > >really also > >move to XML. > >Note that openMRS uses XML rather extensively. > Indeed, any application > >based on > >Java, or more specifically J2EE, would almost > automatically use XML. > > > >A compromise would be to use the XML wrappers for > HL7 v2.3-2.5. Fairly easy - > >just use one of the conversion tools for v2.X -> > v2.X XML. Both VistA and > >openMRS would have to adopt this (in addition to > everybody else). > > > >Another option would be to use "native" XML and > just agree on the terminology > >(elements). The common terminology would be derived > from the mappings of each > >data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR > or whatever is agreed on. > >The Java-based applications should not have much > difficulty with this, > >once the > >data maps are aligned. (I have found that > IndivoHealth, which seems to be the > >engine behind MyOSCAR, has also opted for XML-based > data structures not > >aligned > >to any single standard.) > > > >I am sure somebody can think of other options. > >It is up to the developers to agree on an option. > >Lee > > > > > > > >------------------------------------------------------------ > >This email was sent from Netspace Webmail: > http://www.netspace.net.au > > > >_______________________________________________ > >FOSS_health mailing list > >FOSS_health@oshca.org > >http://mailman.oshca.org/mailman/listinfo.cgi/foss_healt > > regds. > boh > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________ Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 From nandalalx at yahoo.com Thu May 24 22:16:51 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <1179993486.5854.88.camel@tchur-laptop> Message-ID: <20070524141651.80205.qmail@web58704.mail.re1.yahoo.com> Tim, Good practical thoughts. You guys go ahead with NetEpi and Sahana using non-HL7 methods and let those who are comfy with HL7v3 do that for OpenMRS and OSCAR Canada. WHo does it first in practical terms to benefit people - wins. Since you are creating something new you are "the tortoise". HL7 v3 implementors comprise "the hare". But the eventual winner is - "the penguin". Nandalal --- Tim Churches wrote: > On Wed, 2007-05-23 at 16:21 -0700, Tom Jones wrote: > > That depends on what level of interoperability we > are discussing. > > Interoperability has several meanings. For > instance, in Lumpkin, John et al > > "National Committee on Vital and Health Statistics > report to the Secretary > > of the US Department of Health and Human Services > on Uniform Data Standards > > for Patient Medical Record Information" July 6, > 2000, p 6, one can find the > > following: > > > > "Interoperability refers to the ability of one > computer system to exchange > > data with another computer system. There are three > levels of > > interoperability. > > . 'Basic' interoperability allows a message from > one computer to be > > received by another but does not require the > ability for the receiving > > computer to interpret the data. > > . 'Functional' interoperability is an intermediate > level that defines > > the structure, or format, of messages (hence the > term message format > > standards). Functional interoperability defines > the syntax of the message. > > It ensures that messages between computers can be > interpreted at the level > > of data fields. For example, when one computer has > a structured data field > > for Ear Exam, that computer should be able to pass > data from that structured > > data field on to another computer and have it > appropriately stored in a > > comparably structured field for Ear Exam in the > receiving computer. Neither > > system has understanding, however, of the meaning > of the data within the > > fields. > > . 'Semantic' interoperability provides common > interpretability, i.e., > > information in the fields within the message can > be used in an intelligent > > manner. At the highest level, semantic > interoperability takes advantage of > > both the structuring of the message and the > codification of the data so that > > the receiving computer can interpret the data." > > > > Up through version 2 of the HL7 messaging > standard, each enterprise created > > its own information model. Within the "pipes and > bars" (or within the XML > > standard used by versions 2.4 - 2.n), the > representation of the content of > > each HL7 message was left up to the enterprise > (and to the vendors servicing > > that enterprise's system needs). While each > enterprise was able to maintain > > a degree of interoperability within its > boundaries, once an enterprise had > > to communicate outside of its boundaries, > effective communication faltered > > because the "optionality" inherent in these older > versions of HL7 prevented > > systems from exchanging the meaning of the message > content. This shortcoming > > was highlighted in an NCVHS report to HHS > Secretary Shalala in 2000. > > > > "Today, these standards have a high degree of > optionality in order to > > accommodate the variability of workflow and > availability of information in > > different care settings. This optionality creates > the need for costly and > > time-consuming customization when implementing > message format standards. In > > addition, vendors and providers have developed > their own implementation > > guides that differ from the standards. Finally, > there is little or no > > conformance testing of message format standards. > > > > Non-standard implementations result in the need > for costly and > > time-consuming customization to allow information > systems to seamlessly > > exchange data with one another. These customized > solutions contribute to > > high cost of systems." > > > > When enterprises merge for business or regulatory > reasons, the need for more > > robust standards for interoperability becomes more > acute. In these merged > > entities, simple graphic display of numerical > laboratory results becomes a > > nightmare, and automated decision support a > virtual impossibility. The > > situation is just as intolerable for the > continuing consolidation of > > commercial hospital groups as it is for the > evolution of government-mandated > > regional healthcare networks. > > > > As the HL7 messaging standards gained wider use > (the majority of automated > > clinical systems take advantage of one or more of > the older versions of > > HL7), recognition of the need to more fully > specify and normalize the > > content of HL7 messages led to the development of > the HL7 Reference > > Information Model (RIM), an integral part of HL7 > version 3 (the messaging > > structure in this version continues the XML > standard established with HL7 > > 2.4). In an early white paper, a committee within > the HL7 organization > > proposed a model for the actual content of an HL7 > message. They believed > > "that the proposed model will pave the way to new > messaging opportunities, > > including quality management, outcome assessment, > decision support, cost > > control, and authenticated, accurate, electronic > medical record > > communication". As work on the RIM progressed, one > can see that its authors' > > collective ambition was to represent the world of > clinical care in a formal > > logic that would allow engineers to write code and > build clinical > > information systems that would more accurately > represent that world. Such > > systems could facilitate more effective electronic > communication among > > clinicians, and they could also cross enterprise > boundaries and therefore be > > truly "patient centric". > > > > The bottom line, in my view, is that HL7 v2.X sets > the bar too low - at > > functional, rather than semantic, > interoperability. HL7 v.3 (which includes > > the RIM) would be a better level. > > I think that is a rather good summary of the > problems with HL7 v2.x. I > would add that the HL7 specifications do not really > address the issue of > what receiving information systems are supposed to > with the the messages > which they are sent. For example, if a pathology > laboratory discovers a > life threatening abnormal result, say a very low > serum potassium level, > then it can send an HL7 result message to the > requesting doctor's > system, and it can even flag in that message that > the result is abnormal > and urgent and life-threatening, but HL7 provides no > mechanism for > directly requesting that the other system bring this > result to the > attention of a relevant human being (probably a > doctor or nurse), nor > does HL7 provide any help with communicating back > that the requested > action was done, or was not done as the case may be. > In other words, HL7 > v2.x defines (rather loosely in most cases) how data > or information > should be formatted and to a lesser or non-existent > extent how data > should be semantically represented, but is > completely silent about what > should be done with that data by the receiving > computer system: actions > are all implicit and have to be worked out on a > case-by-case basis. What > is actually needed is a mechanism for receiving > systems to advertise > what actions they are able or willing to perform, > and a mechanism to > explicitly request one or more of those actions when > sending data to > that system. In order words, a remote procedure > calling system. CORBA > and CORBAmed had all this a decade or more ago, but > HL7 won out over > CORBAmed for various reasons. Thus, apart from > solving all the problems > with the optionality of the HL7 v2.x specifications > and the many > semantic encoding issues which HL7 v2.x does not > address, there is also > === message truncated === ____________________________________________________________________________________Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From wwilson at umich.edu Thu May 24 23:34:13 2007 From: wwilson at umich.edu (Wayne Wilson) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <20070524141651.80205.qmail@web58704.mail.re1.yahoo.com> References: <20070524141651.80205.qmail@web58704.mail.re1.yahoo.com> Message-ID: On May 24, 2007, at 10:16 AM, Nandalal Gunaratne wrote: > HL7v3 do that > for OpenMRS and OSCAR Canada. > In my past life we were forced to use a HL7V2 'hub' machine in order to reduce the expansion of interfaces and to do the translation of the messages into a format other systems would accept. This hub is in place at nearly all US major Hospitals. Questions: I know of no production implementations of HL7v3 so I don't know whether the hub and spoke model is still needed. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070524/361f6f14/PGP.pgp From tom.jones at tolvenhealth.com Fri May 25 01:21:59 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: Message-ID: I believe that production implementations of HL7 v3 can be located on the HL7 web site in the "early adopters" group. Tom -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of Wayne Wilson Sent: Thursday, May 24, 2007 8:34 AM To: foss_health@oshca.org Subject: Re: [FOSS_health] Re: interoperability On May 24, 2007, at 10:16 AM, Nandalal Gunaratne wrote: > HL7v3 do that > for OpenMRS and OSCAR Canada. > In my past life we were forced to use a HL7V2 'hub' machine in order to reduce the expansion of interfaces and to do the translation of the messages into a format other systems would accept. This hub is in place at nearly all US major Hospitals. Questions: I know of no production implementations of HL7v3 so I don't know whether the hub and spoke model is still needed. From tom.jones at tolvenhealth.com Fri May 25 01:34:43 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <1179993486.5854.88.camel@tchur-laptop> Message-ID: I am going to reflect on the excerpt below: "For example, if a pathology laboratory discovers a life threatening abnormal result, say a very low serum potassium level, then it can send an HL7 result message to the requesting doctor's system, and it can even flag in that message that the result is abnormal and urgent and life-threatening, but HL7 provides no mechanism for directly requesting that the other system bring this result to the attention of a relevant human being (probably a doctor or nurse), nor does HL7 provide any help with communicating back that the requested action was done, or was not done as the case may be. In other words, HL7 v2.x defines (rather loosely in most cases) how data or information should be formatted and to a lesser or non-existent extent how data should be semantically represented, but is completely silent about what should be done with that data by the receiving computer system: actions are all implicit and have to be worked out on a case-by-case basis." I am not sure that HL7 can actually dive into the realm outlined above. There is contextual information that is required even for the very low serum potassium. Considerations include: 1) The potassium has been this low for days; I have repeatedly acknowledged my awareness of the situation, so why do you keep bothering me? 2) I have already taken appropriate action based on the previous low potassium Moreover, it is important to make a reasonable distinction between CDD (clinical data definitions) and CDS (clinical decision support). It is absolutely essential to have crisp clinical data definitions (what is an "allergy"? for instance) with appropriate constraints and with appropriate terminology binding so that the instantiated data can be an unambiguous fuel for CDS. www.wikihit.org is trying to gather both CDDs and CDS rules and establish the links between them. In short, the sponsoring enterprise needs to author/adopt CDS rules for its users and HL7 should have a role in designing tools for development as well as for constraints on CDDs. -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of Tim Churches Sent: Thursday, May 24, 2007 12:58 AM To: foss_health@oshca.org Subject: RE: [FOSS_health] Re: interoperability On Wed, 2007-05-23 at 16:21 -0700, Tom Jones wrote: > That depends on what level of interoperability we are discussing. > Interoperability has several meanings. For instance, in Lumpkin, John et al > "National Committee on Vital and Health Statistics report to the Secretary > of the US Department of Health and Human Services on Uniform Data Standards > for Patient Medical Record Information" July 6, 2000, p 6, one can find the > following: > > "Interoperability refers to the ability of one computer system to exchange > data with another computer system. There are three levels of > interoperability. > . 'Basic' interoperability allows a message from one computer to be > received by another but does not require the ability for the receiving > computer to interpret the data. > . 'Functional' interoperability is an intermediate level that defines > the structure, or format, of messages (hence the term message format > standards). Functional interoperability defines the syntax of the message. > It ensures that messages between computers can be interpreted at the level > of data fields. For example, when one computer has a structured data field > for Ear Exam, that computer should be able to pass data from that structured > data field on to another computer and have it appropriately stored in a > comparably structured field for Ear Exam in the receiving computer. Neither > system has understanding, however, of the meaning of the data within the > fields. > . 'Semantic' interoperability provides common interpretability, i.e., > information in the fields within the message can be used in an intelligent > manner. At the highest level, semantic interoperability takes advantage of > both the structuring of the message and the codification of the data so that > the receiving computer can interpret the data." > > Up through version 2 of the HL7 messaging standard, each enterprise created > its own information model. Within the "pipes and bars" (or within the XML > standard used by versions 2.4 - 2.n), the representation of the content of > each HL7 message was left up to the enterprise (and to the vendors servicing > that enterprise's system needs). While each enterprise was able to maintain > a degree of interoperability within its boundaries, once an enterprise had > to communicate outside of its boundaries, effective communication faltered > because the "optionality" inherent in these older versions of HL7 prevented > systems from exchanging the meaning of the message content. This shortcoming > was highlighted in an NCVHS report to HHS Secretary Shalala in 2000. > > "Today, these standards have a high degree of optionality in order to > accommodate the variability of workflow and availability of information in > different care settings. This optionality creates the need for costly and > time-consuming customization when implementing message format standards. In > addition, vendors and providers have developed their own implementation > guides that differ from the standards. Finally, there is little or no > conformance testing of message format standards. > > Non-standard implementations result in the need for costly and > time-consuming customization to allow information systems to seamlessly > exchange data with one another. These customized solutions contribute to > high cost of systems." > > When enterprises merge for business or regulatory reasons, the need for more > robust standards for interoperability becomes more acute. In these merged > entities, simple graphic display of numerical laboratory results becomes a > nightmare, and automated decision support a virtual impossibility. The > situation is just as intolerable for the continuing consolidation of > commercial hospital groups as it is for the evolution of government-mandated > regional healthcare networks. > > As the HL7 messaging standards gained wider use (the majority of automated > clinical systems take advantage of one or more of the older versions of > HL7), recognition of the need to more fully specify and normalize the > content of HL7 messages led to the development of the HL7 Reference > Information Model (RIM), an integral part of HL7 version 3 (the messaging > structure in this version continues the XML standard established with HL7 > 2.4). In an early white paper, a committee within the HL7 organization > proposed a model for the actual content of an HL7 message. They believed > "that the proposed model will pave the way to new messaging opportunities, > including quality management, outcome assessment, decision support, cost > control, and authenticated, accurate, electronic medical record > communication". As work on the RIM progressed, one can see that its authors' > collective ambition was to represent the world of clinical care in a formal > logic that would allow engineers to write code and build clinical > information systems that would more accurately represent that world. Such > systems could facilitate more effective electronic communication among > clinicians, and they could also cross enterprise boundaries and therefore be > truly "patient centric". > > The bottom line, in my view, is that HL7 v2.X sets the bar too low - at > functional, rather than semantic, interoperability. HL7 v.3 (which includes > the RIM) would be a better level. I think that is a rather good summary of the problems with HL7 v2.x. I would add that the HL7 specifications do not really address the issue of what receiving information systems are supposed to with the the messages which they are sent. For example, if a pathology laboratory discovers a life threatening abnormal result, say a very low serum potassium level, then it can send an HL7 result message to the requesting doctor's system, and it can even flag in that message that the result is abnormal and urgent and life-threatening, but HL7 provides no mechanism for directly requesting that the other system bring this result to the attention of a relevant human being (probably a doctor or nurse), nor does HL7 provide any help with communicating back that the requested action was done, or was not done as the case may be. In other words, HL7 v2.x defines (rather loosely in most cases) how data or information should be formatted and to a lesser or non-existent extent how data should be semantically represented, but is completely silent about what should be done with that data by the receiving computer system: actions are all implicit and have to be worked out on a case-by-case basis. What is actually needed is a mechanism for receiving systems to advertise what actions they are able or willing to perform, and a mechanism to explicitly request one or more of those actions when sending data to that system. In order words, a remote procedure calling system. CORBA and CORBAmed had all this a decade or more ago, but HL7 won out over CORBAmed for various reasons. Thus, apart from solving all the problems with the optionality of the HL7 v2.x specifications and the many semantic encoding issues which HL7 v2.x does not address, there is also the problem of negotiating what receiving systems are supposed to do with the HL7 messages which they receive, and that ends up being implicit and again worked out on a case-by-case basis. Now, none of these issues mean that one should not use HL7 v2.x, just that one needs to be aware that the decision to use HL7 v2.x is only a very partial solution to the interoperability problem, and that in almost all cases, a lot more work will be needed to either define additional (usually national, regional or local) standards and protocols layered on top of HL7 v2.x for specific purposes (eg path lab results reporting), or a lot of case-by-case, point-to-point negotiation and pre-processing and post-processing of HL7 messages will be needed in order to achieve useful levels of interoperability. That's why I opined at the OSHCA conference that the decision to use HL7 v2.x in any interoperability circumstance should be a considered one, not an automatic one, and that HL7 is not a panacea, and in some cases it may be better to use a simpler, more light-weight mechanisms to exchange data between health applications. Perhaps openEHR and/or HL7 v3.x will solve these problems, but as various people have said, practical implementations of these are still some way off and we need to get on with life (and death) in the meantime. The other point regarding HL7 is that its whole interoperability model is based on the assumption that health care applications are black boxes and that their internal data models and data representations can't be examined, modified or augmented - hence the need for a single comprehensive standard (which is supposed to be HL7). Of course, that model is valid for almost all closed-source software, but it is not true of open-source health software. When considering interoperability of open-source information systems, other models are possible. Underlying databases and data stores can often be accessed directly, it may be possible to actually embed one open-source application in another, or special-purpose data interchange modules can be written. For example, say I want SAHANA to exchange data with NetEpi. The traditional approach is to look at the HL7 specifications, work out which message types and message segments are most appropriate, and for the developers of each of the applications to add the ability to emit and consume HL7 messages which are compliant with the relevant aspects and parts of the HL7 specification. Of course, the actually data items collected by SAHANA and NetEpi are quite volatile and dynamic (that is, the data which needs to be exchanged will change as a disaster or a disease outbreak develops and unfolds), and HL7 v2.x does not handle changing data requirements very nicely at all. But alternative approaches are possible. For example, as a NetEpi developer, I can download all the SAHANA source code, set up an instance of it, and write a plug-in module or code patch for SAHANA which will produce data in exactly the form that NetEpi requires - without all the overhead of pouring through 700 pages of HL7 v2.x specifications, then having to augment those specifications in any case, write up those augmented specifications, send them tot he SAHAN people and try to get them to implement them. Or I can write a NetEpi extension to directly access the underlying SAHANA database. Or both SAHANA and NetEpi can agree to use XML-RPC or some other simple mechanism to interchange data and to remotely cause specific actions to occur in each others' systems. Of course, the objection will be raised that it will take more resources to define and create such special-purpose interfaces than it would to use a "standard" HL7 interface. The problem is, as has been discussed, that HL7 v2.x is an insufficient standard in so many respects, and thus it may, in many circumstances, be harder and more resource intensive, even in the long-term, to use it than to ignore it. Also, health applications and information systems themselves are in a constant state of development and change (particularly open-source applications), and so ongoing maintenance of any interoperability mechanism, whether it involves HL7 or not, will be needed in any case. Finally, open-source health information systems, particularly those deployed in developing and transitional countries and those deployed in community settings as opposed to hospitals and large clinics, should not allow themselves to be dictated to by a "standard" which is primarily designed to help run large hospitals in rich countries. After all, there is not exactly a lot of evidence from rich countries that have adopted HL7 v2.x widely that it is a better solution than other approaches. There are so many stories of systems which are supposedly "HL7" compliant failing to interoperate properly, or only being able to interoperate after a lot of case-by-case and point-to-point effort and money is expended. Open-source health systems should only use what has been demonstrated to work well, and should feel free to explore alternatives to HL7. Remember, what matters is that patient care and public health is improved, not that systems are compliant with arbitrary information standards developed in rich countries to run their well-resourced hospitals. Let's not put the cart before the horse. OK, having said all that, what would be really fascinating is one or more case studies in which interoperability between two or more open-source health information systems was implemented using a traditional, HL7 v2.x approach, and in parallel was implemented using a more ad hoc, light-weight approach (or approaches). Costs, time, ease of implementation and reliability and utility of the resulting interoperability could be compared. Finally, I should add that in my work in public health surveillance, we do use HL7 v2.x. That is why I am aware of the issues I have outlined above. In developed countries like Australia, there is little choice but to use HL7 v2.x. But in other settings where financial resources for health care are far less, please do consider alternatives, even if they are only temporary while waiting for HL7 v3.x and openEHR to be finished and become easy to use and well-supported. Tim C > -----Original Message----- > From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] > On Behalf Of lseldon@netspace.net.au > Sent: Wednesday, May 23, 2007 12:00 AM > To: foss_health@oshca.org > Subject: [FOSS_health] Re: interoperability > > Interoperability - Message standards > > Some people seem to be interested in pursuing this. > I have had more thoughts since my original proposal. > > The easiest path would be to go with HL7 v2.X. VistA already supports that - > so > it could possibly be used as a "test engine". openMRS claims to have > implemented > HL7 messages, but I am having trouble pinpointing exactly how. I have > already > pointed to numerous tools for this standard. > > However, there is a problem. HL7 v2.X is "old technology" and even the > standards-makers are moving to XML. Therefore, OSHCA and FOSS should really > also > move to XML. > Note that openMRS uses XML rather extensively. Indeed, any application based > on > Java, or more specifically J2EE, would almost automatically use XML. > > A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly easy > - > just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and > openMRS would have to adopt this (in addition to everybody else). > > Another option would be to use "native" XML and just agree on the > terminology > (elements). The common terminology would be derived from the mappings of > each > data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed > on. > The Java-based applications should not have much difficulty with this, once > the > data maps are aligned. (I have found that IndivoHealth, which seems to be > the > engine behind MyOSCAR, has also opted for XML-based data structures not > aligned > to any single standard.) > > I am sure somebody can think of other options. > It is up to the developers to agree on an option. > Lee > > > > ------------------------------------------------------------ > This email was sent from Netspace Webmail: http://www.netspace.net.au > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From wwilson at umich.edu Fri May 25 02:44:35 2007 From: wwilson at umich.edu (Wayne Wilson) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability Message-ID: <20070524144435.BTB60591@thymus.msis.med.umich.edu> > >I believe that production implementations of HL7 v3 can be located on the >HL7 web site in the "early adopters" group. > Thanks, I was last a member of HL7 over 5 years ago and v3 was still being agreed upon. I have seen no press nor heard no mention of v3 since then. But then I don't travel in those circles anymore so that is understandable. I would like to repeat my query as to whether HL7 hubs are still going to needed for v3? From tom.jones at tolvenhealth.com Fri May 25 03:02:43 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <20070524144435.BTB60591@thymus.msis.med.umich.edu> Message-ID: I think that the hub and spoke approach is more efficient than proliferating point to point approaches -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of Wayne Wilson Sent: Thursday, May 24, 2007 11:45 AM To: foss_health@oshca.org Subject: RE: [FOSS_health] Re: interoperability > >I believe that production implementations of HL7 v3 can be located on the >HL7 web site in the "early adopters" group. > Thanks, I was last a member of HL7 over 5 years ago and v3 was still being agreed upon. I have seen no press nor heard no mention of v3 since then. But then I don't travel in those circles anymore so that is understandable. I would like to repeat my query as to whether HL7 hubs are still going to needed for v3? _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From christian.heller at tuxtax.de Fri May 25 03:37:34 2007 From: christian.heller at tuxtax.de (Christian Heller) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <1179903591.4653e667359df@webmail.netspace.net.au> References: <7C4615229DD21546B2399F446305D82A19DBC2@balrog.mrcad.mrc.ac.za> <4653A26F.7000800@pc.jaring.my> <1179903591.4653e667359df@webmail.netspace.net.au> Message-ID: <200705242137.34358.christian.heller@tuxtax.de> Hello Lee, > Interoperability - Message standards > > Some people seem to be interested in pursuing this. > I have had more thoughts since my original proposal. [..] I do not have time to commit to the project, but would like to give my opinion, if possible. I vote for your proposal to stick with XML. Also, I do not recommend using HL7 RIM3 since it is a complex domain model to be used in application frameworks for building standalone application systems, but not suitable for data interchange. HL7 CDA might be a better solution. OpenEHR is very complex and not mature in my eyes (my opinion). HDTF (CORBAmed) is o.k. and might be faster than an XML-based approach, but brings with some overhead, needs IDL interfaces, an ORB process running etc. and not many programmers know about CORBA any longer. I wonder what happened to HXP, in which OSCAR was involved? In my opinion, this is the way to go. Start simple and get some data exchanged via XML, as prototype solution. Then think closely about the XML format and refine it. You may also want to have a look at CYBOL, an XML-based format described here (DTD, XSD, EBNF): http://cybop.berlios.de/cybol/index.html It has just four tags and four attributes and is very flexible, yet able to hold meta information (the third level :-). I just copy the DTD here: Here are some example models: http://cvs.berlios.de/cgi-bin/viewcvs.cgi/cybop/examples/helloworld/greeting.cybol?rev=1.2&content-type=text/vnd.viewcvs-markup http://cvs.berlios.de/cgi-bin/viewcvs.cgi/cybop/examples/helloworld/startup.cybol?rev=1.10&content-type=text/vnd.viewcvs-markup Note, that "state models" (the first link being part of a textual user interface) and "logic models" (the second link representing the startup algorithm) are represented in the same way, as opposed to traditional programming languages having a different syntax for structures/ classes and methods/ functions/ procedures. Christian From tim.churches at gmail.com Fri May 25 05:11:13 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <4655e166.158e37f3.5cfd.ffffa49dSMTPIN_ADDED@mx.google.com> References: <20070524144435.BTB60591@thymus.msis.med.umich.edu> <4655e166.158e37f3.5cfd.ffffa49dSMTPIN_ADDED@mx.google.com> Message-ID: <7bb0495c0705241411x7d27b465yf119f7c69f5e2489@mail.gmail.com> On 25/05/07, Tom Jones wrote: > > I think that the hub and spoke approach is more efficient than > proliferating > point to point approaches Yes, that is the received wisdom, but I question whether it is actually the case, because the use of a "hub" presumes a common, well-specified data exchange format that doesn't actually exist in practice - it may be possible to use HL7 v2.x as a starting point, but a lot more work then needs to be done by all stakeholders in defining that common format. Committees are convened, many meetings happen, years pass, and finally some lowest common denominator emerges which no-one is entirely happy with. Then some interoperability is actually attempted and everyone realises that it needs to be fine-tuned on a point-to-point basis anyway. What I am suggesting is just get on with it, point-to-point if necessary, work out issues at a practical level in actual interoperability implementations between systems for practical purposes, and then step back and consider more general approaches. Ah, but the point-to-point interfaces might need to be re-done. So what? Software is ephemeral, it is not a stone monument, it always needs to be re-done, and we are talking about re-doing just days or weeks or work, not person-decades. Don't get bogged down trying to solve generalised future interoperability problems. Solve specific interoperability problems now instead. Tim C -----Original Message----- > From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] > On Behalf Of Wayne Wilson > Sent: Thursday, May 24, 2007 11:45 AM > To: foss_health@oshca.org > Subject: RE: [FOSS_health] Re: interoperability > > > > >I believe that production implementations of HL7 v3 can be located on the > >HL7 web site in the "early adopters" group. > > > Thanks, I was last a member of HL7 over 5 years ago and v3 was still being > agreed upon. I have seen no press nor heard no mention of v3 since then. > But then I don't travel in those circles anymore so that is > understandable. > > I would like to repeat my query as to whether HL7 hubs are still going to > needed for v3? > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070525/62095f4b/attachment.html From tim.churches at gmail.com Fri May 25 05:18:02 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <20070524141651.80205.qmail@web58704.mail.re1.yahoo.com> References: <1179993486.5854.88.camel@tchur-laptop> <20070524141651.80205.qmail@web58704.mail.re1.yahoo.com> Message-ID: <7bb0495c0705241418yc4284ebt3106673d84d814f7@mail.gmail.com> On 25/05/07, Nandalal Gunaratne wrote: > > Tim, > > Good practical thoughts. > > You guys go ahead with NetEpi and Sahana using non-HL7 > methods and let those who are comfy with HL7v3 do that > for OpenMRS and OSCAR Canada. Sure. I just don't want "interoperability" to be narrowly defined in teh open-source context and having to use a particular mechanism. Whatever works best in each situation, please. WHo does it first in practical terms to benefit people > - wins. Since you are creating something new you are > "the tortoise". HL7 v3 implementors comprise "the > hare". I think HL7 v3.x is more an elephant. Which is fine if you want to carry the prince and his entire hunting party on your back. But for other situations, a horse, or a donkey, or a rickshaw, or a bicycle might be faster. But the eventual winner is - "the penguin". Um, OK. Tim C --- Tim Churches wrote: > > > On Wed, 2007-05-23 at 16:21 -0700, Tom Jones wrote: > > > That depends on what level of interoperability we > > are discussing. > > > Interoperability has several meanings. For > > instance, in Lumpkin, John et al > > > "National Committee on Vital and Health Statistics > > report to the Secretary > > > of the US Department of Health and Human Services > > on Uniform Data Standards > > > for Patient Medical Record Information" July 6, > > 2000, p 6, one can find the > > > following: > > > > > > "Interoperability refers to the ability of one > > computer system to exchange > > > data with another computer system. There are three > > levels of > > > interoperability. > > > . 'Basic' interoperability allows a message from > > one computer to be > > > received by another but does not require the > > ability for the receiving > > > computer to interpret the data. > > > . 'Functional' interoperability is an intermediate > > level that defines > > > the structure, or format, of messages (hence the > > term message format > > > standards). Functional interoperability defines > > the syntax of the message. > > > It ensures that messages between computers can be > > interpreted at the level > > > of data fields. For example, when one computer has > > a structured data field > > > for Ear Exam, that computer should be able to pass > > data from that structured > > > data field on to another computer and have it > > appropriately stored in a > > > comparably structured field for Ear Exam in the > > receiving computer. Neither > > > system has understanding, however, of the meaning > > of the data within the > > > fields. > > > . 'Semantic' interoperability provides common > > interpretability, i.e., > > > information in the fields within the message can > > be used in an intelligent > > > manner. At the highest level, semantic > > interoperability takes advantage of > > > both the structuring of the message and the > > codification of the data so that > > > the receiving computer can interpret the data." > > > > > > Up through version 2 of the HL7 messaging > > standard, each enterprise created > > > its own information model. Within the "pipes and > > bars" (or within the XML > > > standard used by versions 2.4 - 2.n), the > > representation of the content of > > > each HL7 message was left up to the enterprise > > (and to the vendors servicing > > > that enterprise's system needs). While each > > enterprise was able to maintain > > > a degree of interoperability within its > > boundaries, once an enterprise had > > > to communicate outside of its boundaries, > > effective communication faltered > > > because the "optionality" inherent in these older > > versions of HL7 prevented > > > systems from exchanging the meaning of the message > > content. This shortcoming > > > was highlighted in an NCVHS report to HHS > > Secretary Shalala in 2000. > > > > > > "Today, these standards have a high degree of > > optionality in order to > > > accommodate the variability of workflow and > > availability of information in > > > different care settings. This optionality creates > > the need for costly and > > > time-consuming customization when implementing > > message format standards. In > > > addition, vendors and providers have developed > > their own implementation > > > guides that differ from the standards. Finally, > > there is little or no > > > conformance testing of message format standards. > > > > > > Non-standard implementations result in the need > > for costly and > > > time-consuming customization to allow information > > systems to seamlessly > > > exchange data with one another. These customized > > solutions contribute to > > > high cost of systems." > > > > > > When enterprises merge for business or regulatory > > reasons, the need for more > > > robust standards for interoperability becomes more > > acute. In these merged > > > entities, simple graphic display of numerical > > laboratory results becomes a > > > nightmare, and automated decision support a > > virtual impossibility. The > > > situation is just as intolerable for the > > continuing consolidation of > > > commercial hospital groups as it is for the > > evolution of government-mandated > > > regional healthcare networks. > > > > > > As the HL7 messaging standards gained wider use > > (the majority of automated > > > clinical systems take advantage of one or more of > > the older versions of > > > HL7), recognition of the need to more fully > > specify and normalize the > > > content of HL7 messages led to the development of > > the HL7 Reference > > > Information Model (RIM), an integral part of HL7 > > version 3 (the messaging > > > structure in this version continues the XML > > standard established with HL7 > > > 2.4). In an early white paper, a committee within > > the HL7 organization > > > proposed a model for the actual content of an HL7 > > message. They believed > > > "that the proposed model will pave the way to new > > messaging opportunities, > > > including quality management, outcome assessment, > > decision support, cost > > > control, and authenticated, accurate, electronic > > medical record > > > communication". As work on the RIM progressed, one > > can see that its authors' > > > collective ambition was to represent the world of > > clinical care in a formal > > > logic that would allow engineers to write code and > > build clinical > > > information systems that would more accurately > > represent that world. Such > > > systems could facilitate more effective electronic > > communication among > > > clinicians, and they could also cross enterprise > > boundaries and therefore be > > > truly "patient centric". > > > > > > The bottom line, in my view, is that HL7 v2.X sets > > the bar too low - at > > > functional, rather than semantic, > > interoperability. HL7 v.3 (which includes > > > the RIM) would be a better level. > > > > I think that is a rather good summary of the > > problems with HL7 v2.x. I > > would add that the HL7 specifications do not really > > address the issue of > > what receiving information systems are supposed to > > with the the messages > > which they are sent. For example, if a pathology > > laboratory discovers a > > life threatening abnormal result, say a very low > > serum potassium level, > > then it can send an HL7 result message to the > > requesting doctor's > > system, and it can even flag in that message that > > the result is abnormal > > and urgent and life-threatening, but HL7 provides no > > mechanism for > > directly requesting that the other system bring this > > result to the > > attention of a relevant human being (probably a > > doctor or nurse), nor > > does HL7 provide any help with communicating back > > that the requested > > action was done, or was not done as the case may be. > > In other words, HL7 > > v2.x defines (rather loosely in most cases) how data > > or information > > should be formatted and to a lesser or non-existent > > extent how data > > should be semantically represented, but is > > completely silent about what > > should be done with that data by the receiving > > computer system: actions > > are all implicit and have to be worked out on a > > case-by-case basis. What > > is actually needed is a mechanism for receiving > > systems to advertise > > what actions they are able or willing to perform, > > and a mechanism to > > explicitly request one or more of those actions when > > sending data to > > that system. In order words, a remote procedure > > calling system. CORBA > > and CORBAmed had all this a decade or more ago, but > > HL7 won out over > > CORBAmed for various reasons. Thus, apart from > > solving all the problems > > with the optionality of the HL7 v2.x specifications > > and the many > > semantic encoding issues which HL7 v2.x does not > > address, there is also > > > === message truncated === > > > > > ____________________________________________________________________________________Yahoo! > oneSearch: Finally, mobile search > that gives answers, not web links. > http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070525/a012f19b/attachment.htm From forslund at mail.com Fri May 25 05:24:05 2007 From: forslund at mail.com (David Forslund) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <200705242137.34358.christian.heller@tuxtax.de> References: <7C4615229DD21546B2399F446305D82A19DBC2@balrog.mrcad.mrc.ac.za> <4653A26F.7000800@pc.jaring.my> <1179903591.4653e667359df@webmail.netspace.net.au> <200705242137.34358.christian.heller@tuxtax.de> Message-ID: <46560275.8060700@mail.com> Christian Heller wrote: > Hello Lee, > > >> Interoperability - Message standards >> >> Some people seem to be interested in pursuing this. >> I have had more thoughts since my original proposal. >> > [..] > > I do not have time to commit to the project, but would like to give > my opinion, if possible. I vote for your proposal to stick with XML. > > Also, I do not recommend using HL7 RIM3 since it is a complex domain > model to be used in application frameworks for building standalone > application systems, but not suitable for data interchange. > HL7 CDA might be a better solution. > The interoperability of FOSS should be in concert with non-FOSS systems, too, which is why standard bodies for interoperability exist. Having interoperability between FOSS systems is valuable, but likely to go very far unless they interoperate with non-FOSS systems. > OpenEHR is very complex and not mature in my eyes (my opinion). > > HDTF (CORBAmed) is o.k. and might be faster than an XML-based approach, > but brings with some overhead, needs IDL interfaces, an ORB process > All of these capabilities come with standard Java, and CORBA solutions are perhaps 10 fold (or more) faster than XML approaches. (The use of the DOM standard adds enormously the the XML bloat, but this can be eliminated). Most of the data movement in the HDTF standards is completely compatible with XML. In our OpenEMed software we use XML extensively and it works well with those standards. > running etc. and not many programmers know about CORBA any longer. > This is probably the biggest barrier even though, IMHO, it is much simpler than Web Services because objects are handled more clearly and it was designed with interoperability from the beginning, while Web Services is not. Doing things in XML does little for interoperability unless one has some common semantics. CORBA doesn't guarantee interoperability. Standard interfaces are what are required. The FOSS folks need to connect up with the HSSP efforts so that one doesn't have to reinvent the wheel. > I wonder what happened to HXP, in which OSCAR was involved? > In my opinion, this is the way to go. Start simple and get some > data exchanged via XML, as prototype solution. > Then think closely about the XML format and refine it. > > ... > Christian > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > Dave Forslund From tom.jones at tolvenhealth.com Thu May 24 21:55:09 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:23 2008 Subject: FW: Re(2): [FOSS_health] Re: interoperability Message-ID: -----Original Message----- From: Tom Jones [mailto:tom.jones@tolvenhealth.com] Sent: Thursday, May 24, 2007 6:54 AM To: 'Boh Heong Yap' Subject: RE: Re(2): [FOSS_health] Re: interoperability I have attached the report in pdf format Tom -----Original Message----- From: Boh Heong Yap [mailto:bhyz@mac.com] Sent: Thursday, May 24, 2007 12:05 AM To: foss_health@oshca.org; Tom Jones Subject: Re(2): [FOSS_health] Re: interoperability tom, you brought up some good points here, what I like is the last part "...once an enterprise had to communicate outside of its boundaries, effective communication faltered because the "optionality" inherent in these older versions of HL7 prevented systems from exchanging the meaning of the message content." This is exactly what is happening here in Malaysia, where the government (Ministry of Healt/MOH) has invested in different proprietry system which claim HL7 compatibility, but cannot interoperate! Can you make that report you mention available to OSHCA members? a PDF would be good. >That depends on what level of interoperability we are discussing. >Interoperability has several meanings. For instance, in Lumpkin, John et al >"National Committee on Vital and Health Statistics report to the Secretary >of the US Department of Health and Human Services on Uniform Data Standards >for Patient Medical Record Information" July 6, 2000, p 6, one can find the >following: > >"Interoperability refers to the ability of one computer system to exchange >data with another computer system. There are three levels of >interoperability. >. 'Basic' interoperability allows a message from one computer to be >received by another but does not require the ability for the receiving >computer to interpret the data. >. 'Functional' interoperability is an intermediate level that defines >the structure, or format, of messages (hence the term message format >standards). Functional interoperability defines the syntax of the message. >It ensures that messages between computers can be interpreted at the level >of data fields. For example, when one computer has a structured data field >for Ear Exam, that computer should be able to pass data from that structured >data field on to another computer and have it appropriately stored in a >comparably structured field for Ear Exam in the receiving computer. Neither >system has understanding, however, of the meaning of the data within the >fields. >. 'Semantic' interoperability provides common interpretability, i.e., >information in the fields within the message can be used in an intelligent >manner. At the highest level, semantic interoperability takes advantage of >both the structuring of the message and the codification of the data so that >the receiving computer can interpret the data." > >Up through version 2 of the HL7 messaging standard, each enterprise created >its own information model. Within the "pipes and bars" (or within the XML >standard used by versions 2.4 - 2.n), the representation of the content of >each HL7 message was left up to the enterprise (and to the vendors servicing >that enterprise's system needs). While each enterprise was able to maintain >a degree of interoperability within its boundaries, once an enterprise had >to communicate outside of its boundaries, effective communication faltered >because the "optionality" inherent in these older versions of HL7 prevented >systems from exchanging the meaning of the message content. This shortcoming >was highlighted in an NCVHS report to HHS Secretary Shalala in 2000. > >"Today, these standards have a high degree of optionality in order to >accommodate the variability of workflow and availability of information in >different care settings. This optionality creates the need for costly and >time-consuming customization when implementing message format standards. In >addition, vendors and providers have developed their own implementation >guides that differ from the standards. Finally, there is little or no >conformance testing of message format standards. > >Non-standard implementations result in the need for costly and >time-consuming customization to allow information systems to seamlessly >exchange data with one another. These customized solutions contribute to >high cost of systems." > >When enterprises merge for business or regulatory reasons, the need for more >robust standards for interoperability becomes more acute. In these merged >entities, simple graphic display of numerical laboratory results becomes a >nightmare, and automated decision support a virtual impossibility. The >situation is just as intolerable for the continuing consolidation of >commercial hospital groups as it is for the evolution of government-mandated >regional healthcare networks. > >As the HL7 messaging standards gained wider use (the majority of automated >clinical systems take advantage of one or more of the older versions of >HL7), recognition of the need to more fully specify and normalize the >content of HL7 messages led to the development of the HL7 Reference >Information Model (RIM), an integral part of HL7 version 3 (the messaging >structure in this version continues the XML standard established with HL7 >2.4). In an early white paper, a committee within the HL7 organization >proposed a model for the actual content of an HL7 message. They believed >"that the proposed model will pave the way to new messaging opportunities, >including quality management, outcome assessment, decision support, cost >control, and authenticated, accurate, electronic medical record >communication". As work on the RIM progressed, one can see that its authors' >collective ambition was to represent the world of clinical care in a formal >logic that would allow engineers to write code and build clinical >information systems that would more accurately represent that world. Such >systems could facilitate more effective electronic communication among >clinicians, and they could also cross enterprise boundaries and therefore be >truly "patient centric". > >The bottom line, in my view, is that HL7 v2.X sets the bar too low - at >functional, rather than semantic, interoperability. HL7 v.3 (which includes >the RIM) would be a better level. > > > >-----Original Message----- >From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] >On Behalf Of lseldon@netspace.net.au >Sent: Wednesday, May 23, 2007 12:00 AM >To: foss_health@oshca.org >Subject: [FOSS_health] Re: interoperability > >Interoperability - Message standards > >Some people seem to be interested in pursuing this. >I have had more thoughts since my original proposal. > >The easiest path would be to go with HL7 v2.X. VistA already supports that - >so >it could possibly be used as a "test engine". openMRS claims to have >implemented >HL7 messages, but I am having trouble pinpointing exactly how. I have >already >pointed to numerous tools for this standard. > >However, there is a problem. HL7 v2.X is "old technology" and even the >standards-makers are moving to XML. Therefore, OSHCA and FOSS should really >also >move to XML. >Note that openMRS uses XML rather extensively. Indeed, any application based >on >Java, or more specifically J2EE, would almost automatically use XML. > >A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly easy >- >just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and >openMRS would have to adopt this (in addition to everybody else). > >Another option would be to use "native" XML and just agree on the >terminology >(elements). The common terminology would be derived from the mappings of >each >data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed >on. >The Java-based applications should not have much difficulty with this, once >the >data maps are aligned. (I have found that IndivoHealth, which seems to be >the >engine behind MyOSCAR, has also opted for XML-based data structures not >aligned >to any single standard.) > >I am sure somebody can think of other options. >It is up to the developers to agree on an option. >Lee > > > regards, -- Boh Heong, Yap email: bhyz@mac.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ncvhs 7_6_00.pdf Type: application/octet-stream Size: 407552 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070524/bbd83588/ncvhs7_6_00.obj From tchur at it.usyd.edu.au Fri May 25 10:16:21 2007 From: tchur at it.usyd.edu.au (Tim Churches) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: References: <20070524141651.80205.qmail@web58704.mail.re1.yahoo.com> Message-ID: <1180059381.5585.9.camel@tchur-laptop> On Thu, 2007-05-24 at 11:34 -0400, Wayne Wilson wrote: > On May 24, 2007, at 10:16 AM, Nandalal Gunaratne wrote: > > > HL7v3 do that > > for OpenMRS and OSCAR Canada. > > > In my past life we were forced to use a HL7V2 'hub' machine in > order to reduce the expansion of interfaces and to do the translation > of the messages into a format other systems would accept. This hub > is in place at nearly all US major Hospitals. Yes, likewise here in Oz. What seems to happen is that when application A needs to talk to application B, HL7 v2.x messages are routed from A to B via the hub. The specifications, details of the format (withing the wide bounds of the HL7 specs) and semantic encoding of the messages from A to B are all worked out and modifications made to A, to B or transformation and translation rules are programmed into the HL7 hub. Then application C comes along and also needs to talk to A and B. More modifications are then needed in C, or possibly A, or more transformation and translation rules are needed in the hub to supply messages to C in exactly the HL7-compatible form it requires. And so on. Thus the "hub-and-spoke" model in effect is just a set of point-to-point interfaces which all happen to route through the same hub. Now, I think that is perfectly OK and entirely pragmatic, and far better to do that than to fall into some sort of interoperability paralysis for want of a more elegant and general solution. But it is provides plenty of motivation for working on better solutions in parallel, and informed by actual interoperability practice. Tim Churches From tchur at it.usyd.edu.au Fri May 25 10:23:05 2007 From: tchur at it.usyd.edu.au (Tim Churches) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability Message-ID: <1180059785.5585.17.camel@tchur-laptop> On Thu, 2007-05-24 at 10:34 -0700, Tom Jones wrote: > I am going to reflect on the excerpt below: > > "For example, if a pathology laboratory discovers a life threatening > abnormal result, say a very low serum potassium level, then it can send an > HL7 result message to the requesting doctor's system, and it can even flag > in that message that the result is abnormal and urgent and life-threatening, > but HL7 provides no mechanism for directly requesting that the other system > bring this result to the attention of a relevant human being (probably a > doctor or nurse), nor does HL7 provide any help with communicating back that > the requested action was done, or was not done as the case may be. In other > words, HL7 v2.x defines (rather loosely in most cases) how data or > information should be formatted and to a lesser or non-existent extent how > data should be semantically represented, but is completely silent about what > should be done with that data by the receiving computer system: actions are > all implicit and have to be worked out on a case-by-case basis." > > I am not sure that HL7 can actually dive into the realm outlined above. > There is contextual information that is required even for the very low serum > potassium. Considerations include: > 1) The potassium has been this low for days; I have repeatedly acknowledged > my awareness of the situation, so why do you keep bothering me? > 2) I have already taken appropriate action based on the previous low > potassium. Sure. That sort of context is what humans are good at considering and making decisions about. Or perhaps in the future, sophisticated decision-support systems. All we want interoperability messaging to be able to do is deliver the message reliable, ensure the message is clear and can be understood, and communicate how the message should be handled. > Moreover, it is important to make a reasonable distinction between CDD > (clinical data definitions) and CDS (clinical decision support). It is > absolutely essential to have crisp clinical data definitions (what is an > "allergy"? for instance) with appropriate constraints and with appropriate > terminology binding so that the instantiated data can be an unambiguous fuel > for CDS. www.wikihit.org is trying to gather both CDDs and CDS rules and > establish the links between them. Sure, no argument there. To add that to HL7 v2.x needs a lot of situation-specific additional specification and agreement. > In short, the sponsoring enterprise needs to author/adopt CDS rules for its > users and HL7 should have a role in designing tools for development as well > as for constraints on CDDs. HL7 has a role in designing constraints and tools? How exactly? Via HL7 ballots? You've lost me there. Tim Churches > -----Original Message----- > From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] > On Behalf Of Tim Churches > Sent: Thursday, May 24, 2007 12:58 AM > To: foss_health@oshca.org > Subject: RE: [FOSS_health] Re: interoperability > > On Wed, 2007-05-23 at 16:21 -0700, Tom Jones wrote: > > That depends on what level of interoperability we are discussing. > > Interoperability has several meanings. For instance, in Lumpkin, John et > al > > "National Committee on Vital and Health Statistics report to the Secretary > > of the US Department of Health and Human Services on Uniform Data > Standards > > for Patient Medical Record Information" July 6, 2000, p 6, one can find > the > > following: > > > > "Interoperability refers to the ability of one computer system to exchange > > data with another computer system. There are three levels of > > interoperability. > > . 'Basic' interoperability allows a message from one computer to be > > received by another but does not require the ability for the receiving > > computer to interpret the data. > > . 'Functional' interoperability is an intermediate level that defines > > the structure, or format, of messages (hence the term message format > > standards). Functional interoperability defines the syntax of the message. > > It ensures that messages between computers can be interpreted at the level > > of data fields. For example, when one computer has a structured data field > > for Ear Exam, that computer should be able to pass data from that > structured > > data field on to another computer and have it appropriately stored in a > > comparably structured field for Ear Exam in the receiving computer. > Neither > > system has understanding, however, of the meaning of the data within the > > fields. > > . 'Semantic' interoperability provides common interpretability, i.e., > > information in the fields within the message can be used in an intelligent > > manner. At the highest level, semantic interoperability takes advantage of > > both the structuring of the message and the codification of the data so > that > > the receiving computer can interpret the data." > > > > Up through version 2 of the HL7 messaging standard, each enterprise > created > > its own information model. Within the "pipes and bars" (or within the XML > > standard used by versions 2.4 - 2.n), the representation of the content of > > each HL7 message was left up to the enterprise (and to the vendors > servicing > > that enterprise's system needs). While each enterprise was able to > maintain > > a degree of interoperability within its boundaries, once an enterprise had > > to communicate outside of its boundaries, effective communication faltered > > because the "optionality" inherent in these older versions of HL7 > prevented > > systems from exchanging the meaning of the message content. This > shortcoming > > was highlighted in an NCVHS report to HHS Secretary Shalala in 2000. > > > > "Today, these standards have a high degree of optionality in order to > > accommodate the variability of workflow and availability of information in > > different care settings. This optionality creates the need for costly and > > time-consuming customization when implementing message format standards. > In > > addition, vendors and providers have developed their own implementation > > guides that differ from the standards. Finally, there is little or no > > conformance testing of message format standards. > > > > Non-standard implementations result in the need for costly and > > time-consuming customization to allow information systems to seamlessly > > exchange data with one another. These customized solutions contribute to > > high cost of systems." > > > > When enterprises merge for business or regulatory reasons, the need for > more > > robust standards for interoperability becomes more acute. In these merged > > entities, simple graphic display of numerical laboratory results becomes a > > nightmare, and automated decision support a virtual impossibility. The > > situation is just as intolerable for the continuing consolidation of > > commercial hospital groups as it is for the evolution of > government-mandated > > regional healthcare networks. > > > > As the HL7 messaging standards gained wider use (the majority of automated > > clinical systems take advantage of one or more of the older versions of > > HL7), recognition of the need to more fully specify and normalize the > > content of HL7 messages led to the development of the HL7 Reference > > Information Model (RIM), an integral part of HL7 version 3 (the messaging > > structure in this version continues the XML standard established with HL7 > > 2.4). In an early white paper, a committee within the HL7 organization > > proposed a model for the actual content of an HL7 message. They believed > > "that the proposed model will pave the way to new messaging opportunities, > > including quality management, outcome assessment, decision support, cost > > control, and authenticated, accurate, electronic medical record > > communication". As work on the RIM progressed, one can see that its > authors' > > collective ambition was to represent the world of clinical care in a > formal > > logic that would allow engineers to write code and build clinical > > information systems that would more accurately represent that world. Such > > systems could facilitate more effective electronic communication among > > clinicians, and they could also cross enterprise boundaries and therefore > be > > truly "patient centric". > > > > The bottom line, in my view, is that HL7 v2.X sets the bar too low - at > > functional, rather than semantic, interoperability. HL7 v.3 (which > includes > > the RIM) would be a better level. > > I think that is a rather good summary of the problems with HL7 v2.x. I > would add that the HL7 specifications do not really address the issue of > what receiving information systems are supposed to with the the messages > which they are sent. For example, if a pathology laboratory discovers a > life threatening abnormal result, say a very low serum potassium level, > then it can send an HL7 result message to the requesting doctor's > system, and it can even flag in that message that the result is abnormal > and urgent and life-threatening, but HL7 provides no mechanism for > directly requesting that the other system bring this result to the > attention of a relevant human being (probably a doctor or nurse), nor > does HL7 provide any help with communicating back that the requested > action was done, or was not done as the case may be. In other words, HL7 > v2.x defines (rather loosely in most cases) how data or information > should be formatted and to a lesser or non-existent extent how data > should be semantically represented, but is completely silent about what > should be done with that data by the receiving computer system: actions > are all implicit and have to be worked out on a case-by-case basis. What > is actually needed is a mechanism for receiving systems to advertise > what actions they are able or willing to perform, and a mechanism to > explicitly request one or more of those actions when sending data to > that system. In order words, a remote procedure calling system. CORBA > and CORBAmed had all this a decade or more ago, but HL7 won out over > CORBAmed for various reasons. Thus, apart from solving all the problems > with the optionality of the HL7 v2.x specifications and the many > semantic encoding issues which HL7 v2.x does not address, there is also > the problem of negotiating what receiving systems are supposed to do > with the HL7 messages which they receive, and that ends up being > implicit and again worked out on a case-by-case basis. > > Now, none of these issues mean that one should not use HL7 v2.x, just > that one needs to be aware that the decision to use HL7 v2.x is only a > very partial solution to the interoperability problem, and that in > almost all cases, a lot more work will be needed to either define > additional (usually national, regional or local) standards and protocols > layered on top of HL7 v2.x for specific purposes (eg path lab results > reporting), or a lot of case-by-case, point-to-point negotiation and > pre-processing and post-processing of HL7 messages will be needed in > order to achieve useful levels of interoperability. > > That's why I opined at the OSHCA conference that the decision to use HL7 > v2.x in any interoperability circumstance should be a considered one, > not an automatic one, and that HL7 is not a panacea, and in some cases > it may be better to use a simpler, more light-weight mechanisms to > exchange data between health applications. > > Perhaps openEHR and/or HL7 v3.x will solve these problems, but as > various people have said, practical implementations of these are still > some way off and we need to get on with life (and death) in the > meantime. > > The other point regarding HL7 is that its whole interoperability model > is based on the assumption that health care applications are black boxes > and that their internal data models and data representations can't be > examined, modified or augmented - hence the need for a single > comprehensive standard (which is supposed to be HL7). Of course, that > model is valid for almost all closed-source software, but it is not true > of open-source health software. When considering interoperability of > open-source information systems, other models are possible. Underlying > databases and data stores can often be accessed directly, it may be > possible to actually embed one open-source application in another, or > special-purpose data interchange modules can be written. For example, > say I want SAHANA to exchange data with NetEpi. The traditional approach > is to look at the HL7 specifications, work out which message types and > message segments are most appropriate, and for the developers of each of > the applications to add the ability to emit and consume HL7 messages > which are compliant with the relevant aspects and parts of the HL7 > specification. Of course, the actually data items collected by SAHANA > and NetEpi are quite volatile and dynamic (that is, the data which needs > to be exchanged will change as a disaster or a disease outbreak develops > and unfolds), and HL7 v2.x does not handle changing data requirements > very nicely at all. But alternative approaches are possible. For > example, as a NetEpi developer, I can download all the SAHANA source > code, set up an instance of it, and write a plug-in module or code patch > for SAHANA which will produce data in exactly the form that NetEpi > requires - without all the overhead of pouring through 700 pages of HL7 > v2.x specifications, then having to augment those specifications in any > case, write up those augmented specifications, send them tot he SAHAN > people and try to get them to implement them. Or I can write a NetEpi > extension to directly access the underlying SAHANA database. Or both > SAHANA and NetEpi can agree to use XML-RPC or some other simple > mechanism to interchange data and to remotely cause specific actions to > occur in each others' systems. > > Of course, the objection will be raised that it will take more resources > to define and create such special-purpose interfaces than it would to > use a "standard" HL7 interface. The problem is, as has been discussed, > that HL7 v2.x is an insufficient standard in so many respects, and thus > it may, in many circumstances, be harder and more resource intensive, > even in the long-term, to use it than to ignore it. Also, health > applications and information systems themselves are in a constant state > of development and change (particularly open-source applications), and > so ongoing maintenance of any interoperability mechanism, whether it > involves HL7 or not, will be needed in any case. Finally, open-source > health information systems, particularly those deployed in developing > and transitional countries and those deployed in community settings as > opposed to hospitals and large clinics, should not allow themselves to > be dictated to by a "standard" which is primarily designed to help run > large hospitals in rich countries. After all, there is not exactly a lot > of evidence from rich countries that have adopted HL7 v2.x widely that > it is a better solution than other approaches. There are so many stories > of systems which are supposedly "HL7" compliant failing to interoperate > properly, or only being able to interoperate after a lot of case-by-case > and point-to-point effort and money is expended. Open-source health > systems should only use what has been demonstrated to work well, and > should feel free to explore alternatives to HL7. Remember, what matters > is that patient care and public health is improved, not that systems are > compliant with arbitrary information standards developed in rich > countries to run their well-resourced hospitals. Let's not put the cart > before the horse. > > OK, having said all that, what would be really fascinating is one or > more case studies in which interoperability between two or more > open-source health information systems was implemented using a > traditional, HL7 v2.x approach, and in parallel was implemented using a > more ad hoc, light-weight approach (or approaches). Costs, time, ease of > implementation and reliability and utility of the resulting > interoperability could be compared. > > Finally, I should add that in my work in public health surveillance, we > do use HL7 v2.x. That is why I am aware of the issues I have outlined > above. In developed countries like Australia, there is little choice but > to use HL7 v2.x. But in other settings where financial resources for > health care are far less, please do consider alternatives, even if they > are only temporary while waiting for HL7 v3.x and openEHR to be finished > and become easy to use and well-supported. > > Tim C > > > -----Original Message----- > > From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] > > On Behalf Of lseldon@netspace.net.au > > Sent: Wednesday, May 23, 2007 12:00 AM > > To: foss_health@oshca.org > > Subject: [FOSS_health] Re: interoperability > > > > Interoperability - Message standards > > > > Some people seem to be interested in pursuing this. > > I have had more thoughts since my original proposal. > > > > The easiest path would be to go with HL7 v2.X. VistA already supports that > - > > so > > it could possibly be used as a "test engine". openMRS claims to have > > implemented > > HL7 messages, but I am having trouble pinpointing exactly how. I have > > already > > pointed to numerous tools for this standard. > > > > However, there is a problem. HL7 v2.X is "old technology" and even the > > standards-makers are moving to XML. Therefore, OSHCA and FOSS should > really > > also > > move to XML. > > Note that openMRS uses XML rather extensively. Indeed, any application > based > > on > > Java, or more specifically J2EE, would almost automatically use XML. > > > > A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly > easy > > - > > just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and > > openMRS would have to adopt this (in addition to everybody else). > > > > Another option would be to use "native" XML and just agree on the > > terminology > > (elements). The common terminology would be derived from the mappings of > > each > > data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed > > on. > > The Java-based applications should not have much difficulty with this, > once > > the > > data maps are aligned. (I have found that IndivoHealth, which seems to be > > the > > engine behind MyOSCAR, has also opted for XML-based data structures not > > aligned > > to any single standard.) > > > > I am sure somebody can think of other options. > > It is up to the developers to agree on an option. > > Lee > > > > > > > > ------------------------------------------------------------ > > This email was sent from Netspace Webmail: http://www.netspace.net.au > > > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From jel at wildmedic.org Fri May 25 10:47:45 2007 From: jel at wildmedic.org (Jel Coward) Date: Sun Jan 27 17:55:23 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <7bb0495c0705241411x7d27b465yf119f7c69f5e2489@mail.gmail.com> References: <20070524144435.BTB60591@thymus.msis.med.umich.edu> <4655e166.158e37f3.5cfd.ffffa49dSMTPIN_ADDED@mx.google.com> <7bb0495c0705241411x7d27b465yf119f7c69f5e2489@mail.gmail.com> Message-ID: <46564E51.2070704@wildmedic.org> Tim C wrote: > Don't get bogged down trying to solve generalised future > interoperability problems. Solve specific interoperability problems now > instead. > Yes, yes and yes. Do it now. Organise it later. So many things die from frustration as the perceived need to build to the big pictures sucks them into the swamp. It is a bit like using an avalanche transceiver. There are described search patterns to use and learn, and much science. But the best piece of advice I ever received when using one was, if it isn't clear what is going on - just move, and move quickly - things then start to become clear. Jel Coward From ddecouteau at sbcglobal.net Fri May 25 10:48:18 2007 From: ddecouteau at sbcglobal.net (Duane DeCouteau) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <1180059785.5585.17.camel@tchur-laptop> References: <1180059785.5585.17.camel@tchur-laptop> Message-ID: <46564E72.4080509@sbcglobal.net> The excerpt and it's implied capabilities are currently being designed and built by our team here in San Diego as part of a Military Health System initiative. Duane Tim Churches wrote: > On Thu, 2007-05-24 at 10:34 -0700, Tom Jones wrote: > >> I am going to reflect on the excerpt below: >> >> "For example, if a pathology laboratory discovers a life threatening >> abnormal result, say a very low serum potassium level, then it can send an >> HL7 result message to the requesting doctor's system, and it can even flag >> in that message that the result is abnormal and urgent and life-threatening, >> but HL7 provides no mechanism for directly requesting that the other system >> bring this result to the attention of a relevant human being (probably a >> doctor or nurse), nor does HL7 provide any help with communicating back that >> the requested action was done, or was not done as the case may be. In other >> words, HL7 v2.x defines (rather loosely in most cases) how data or >> information should be formatted and to a lesser or non-existent extent how >> data should be semantically represented, but is completely silent about what >> should be done with that data by the receiving computer system: actions are >> all implicit and have to be worked out on a case-by-case basis." >> >> I am not sure that HL7 can actually dive into the realm outlined above. >> There is contextual information that is required even for the very low serum >> potassium. Considerations include: >> 1) The potassium has been this low for days; I have repeatedly acknowledged >> my awareness of the situation, so why do you keep bothering me? >> 2) I have already taken appropriate action based on the previous low >> potassium. >> > > Sure. That sort of context is what humans are good at considering and > making decisions about. Or perhaps in the future, sophisticated > decision-support systems. All we want interoperability messaging to be > able to do is deliver the message reliable, ensure the message is clear > and can be understood, and communicate how the message should be > handled. > > >> Moreover, it is important to make a reasonable distinction between CDD >> (clinical data definitions) and CDS (clinical decision support). It is >> absolutely essential to have crisp clinical data definitions (what is an >> "allergy"? for instance) with appropriate constraints and with appropriate >> terminology binding so that the instantiated data can be an unambiguous fuel >> for CDS. www.wikihit.org is trying to gather both CDDs and CDS rules and >> establish the links between them. >> > > Sure, no argument there. To add that to HL7 v2.x needs a lot of > situation-specific additional specification and agreement. > > >> In short, the sponsoring enterprise needs to author/adopt CDS rules for its >> users and HL7 should have a role in designing tools for development as well >> as for constraints on CDDs. >> > > HL7 has a role in designing constraints and tools? How exactly? Via HL7 > ballots? You've lost me there. > > Tim Churches > > >> -----Original Message----- >> From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] >> On Behalf Of Tim Churches >> Sent: Thursday, May 24, 2007 12:58 AM >> To: foss_health@oshca.org >> Subject: RE: [FOSS_health] Re: interoperability >> >> On Wed, 2007-05-23 at 16:21 -0700, Tom Jones wrote: >> >>> That depends on what level of interoperability we are discussing. >>> Interoperability has several meanings. For instance, in Lumpkin, John et >>> >> al >> >>> "National Committee on Vital and Health Statistics report to the Secretary >>> of the US Department of Health and Human Services on Uniform Data >>> >> Standards >> >>> for Patient Medical Record Information" July 6, 2000, p 6, one can find >>> >> the >> >>> following: >>> >>> "Interoperability refers to the ability of one computer system to exchange >>> data with another computer system. There are three levels of >>> interoperability. >>> . 'Basic' interoperability allows a message from one computer to be >>> received by another but does not require the ability for the receiving >>> computer to interpret the data. >>> . 'Functional' interoperability is an intermediate level that defines >>> the structure, or format, of messages (hence the term message format >>> standards). Functional interoperability defines the syntax of the message. >>> It ensures that messages between computers can be interpreted at the level >>> of data fields. For example, when one computer has a structured data field >>> for Ear Exam, that computer should be able to pass data from that >>> >> structured >> >>> data field on to another computer and have it appropriately stored in a >>> comparably structured field for Ear Exam in the receiving computer. >>> >> Neither >> >>> system has understanding, however, of the meaning of the data within the >>> fields. >>> . 'Semantic' interoperability provides common interpretability, i.e., >>> information in the fields within the message can be used in an intelligent >>> manner. At the highest level, semantic interoperability takes advantage of >>> both the structuring of the message and the codification of the data so >>> >> that >> >>> the receiving computer can interpret the data." >>> >>> Up through version 2 of the HL7 messaging standard, each enterprise >>> >> created >> >>> its own information model. Within the "pipes and bars" (or within the XML >>> standard used by versions 2.4 - 2.n), the representation of the content of >>> each HL7 message was left up to the enterprise (and to the vendors >>> >> servicing >> >>> that enterprise's system needs). While each enterprise was able to >>> >> maintain >> >>> a degree of interoperability within its boundaries, once an enterprise had >>> to communicate outside of its boundaries, effective communication faltered >>> because the "optionality" inherent in these older versions of HL7 >>> >> prevented >> >>> systems from exchanging the meaning of the message content. This >>> >> shortcoming >> >>> was highlighted in an NCVHS report to HHS Secretary Shalala in 2000. >>> >>> "Today, these standards have a high degree of optionality in order to >>> accommodate the variability of workflow and availability of information in >>> different care settings. This optionality creates the need for costly and >>> time-consuming customization when implementing message format standards. >>> >> In >> >>> addition, vendors and providers have developed their own implementation >>> guides that differ from the standards. Finally, there is little or no >>> conformance testing of message format standards. >>> >>> Non-standard implementations result in the need for costly and >>> time-consuming customization to allow information systems to seamlessly >>> exchange data with one another. These customized solutions contribute to >>> high cost of systems." >>> >>> When enterprises merge for business or regulatory reasons, the need for >>> >> more >> >>> robust standards for interoperability becomes more acute. In these merged >>> entities, simple graphic display of numerical laboratory results becomes a >>> nightmare, and automated decision support a virtual impossibility. The >>> situation is just as intolerable for the continuing consolidation of >>> commercial hospital groups as it is for the evolution of >>> >> government-mandated >> >>> regional healthcare networks. >>> >>> As the HL7 messaging standards gained wider use (the majority of automated >>> clinical systems take advantage of one or more of the older versions of >>> HL7), recognition of the need to more fully specify and normalize the >>> content of HL7 messages led to the development of the HL7 Reference >>> Information Model (RIM), an integral part of HL7 version 3 (the messaging >>> structure in this version continues the XML standard established with HL7 >>> 2.4). In an early white paper, a committee within the HL7 organization >>> proposed a model for the actual content of an HL7 message. They believed >>> "that the proposed model will pave the way to new messaging opportunities, >>> including quality management, outcome assessment, decision support, cost >>> control, and authenticated, accurate, electronic medical record >>> communication". As work on the RIM progressed, one can see that its >>> >> authors' >> >>> collective ambition was to represent the world of clinical care in a >>> >> formal >> >>> logic that would allow engineers to write code and build clinical >>> information systems that would more accurately represent that world. Such >>> systems could facilitate more effective electronic communication among >>> clinicians, and they could also cross enterprise boundaries and therefore >>> >> be >> >>> truly "patient centric". >>> >>> The bottom line, in my view, is that HL7 v2.X sets the bar too low - at >>> functional, rather than semantic, interoperability. HL7 v.3 (which >>> >> includes >> >>> the RIM) would be a better level. >>> >> I think that is a rather good summary of the problems with HL7 v2.x. I >> would add that the HL7 specifications do not really address the issue of >> what receiving information systems are supposed to with the the messages >> which they are sent. For example, if a pathology laboratory discovers a >> life threatening abnormal result, say a very low serum potassium level, >> then it can send an HL7 result message to the requesting doctor's >> system, and it can even flag in that message that the result is abnormal >> and urgent and life-threatening, but HL7 provides no mechanism for >> directly requesting that the other system bring this result to the >> attention of a relevant human being (probably a doctor or nurse), nor >> does HL7 provide any help with communicating back that the requested >> action was done, or was not done as the case may be. In other words, HL7 >> v2.x defines (rather loosely in most cases) how data or information >> should be formatted and to a lesser or non-existent extent how data >> should be semantically represented, but is completely silent about what >> should be done with that data by the receiving computer system: actions >> are all implicit and have to be worked out on a case-by-case basis. What >> is actually needed is a mechanism for receiving systems to advertise >> what actions they are able or willing to perform, and a mechanism to >> explicitly request one or more of those actions when sending data to >> that system. In order words, a remote procedure calling system. CORBA >> and CORBAmed had all this a decade or more ago, but HL7 won out over >> CORBAmed for various reasons. Thus, apart from solving all the problems >> with the optionality of the HL7 v2.x specifications and the many >> semantic encoding issues which HL7 v2.x does not address, there is also >> the problem of negotiating what receiving systems are supposed to do >> with the HL7 messages which they receive, and that ends up being >> implicit and again worked out on a case-by-case basis. >> >> Now, none of these issues mean that one should not use HL7 v2.x, just >> that one needs to be aware that the decision to use HL7 v2.x is only a >> very partial solution to the interoperability problem, and that in >> almost all cases, a lot more work will be needed to either define >> additional (usually national, regional or local) standards and protocols >> layered on top of HL7 v2.x for specific purposes (eg path lab results >> reporting), or a lot of case-by-case, point-to-point negotiation and >> pre-processing and post-processing of HL7 messages will be needed in >> order to achieve useful levels of interoperability. >> >> That's why I opined at the OSHCA conference that the decision to use HL7 >> v2.x in any interoperability circumstance should be a considered one, >> not an automatic one, and that HL7 is not a panacea, and in some cases >> it may be better to use a simpler, more light-weight mechanisms to >> exchange data between health applications. >> >> Perhaps openEHR and/or HL7 v3.x will solve these problems, but as >> various people have said, practical implementations of these are still >> some way off and we need to get on with life (and death) in the >> meantime. >> >> The other point regarding HL7 is that its whole interoperability model >> is based on the assumption that health care applications are black boxes >> and that their internal data models and data representations can't be >> examined, modified or augmented - hence the need for a single >> comprehensive standard (which is supposed to be HL7). Of course, that >> model is valid for almost all closed-source software, but it is not true >> of open-source health software. When considering interoperability of >> open-source information systems, other models are possible. Underlying >> databases and data stores can often be accessed directly, it may be >> possible to actually embed one open-source application in another, or >> special-purpose data interchange modules can be written. For example, >> say I want SAHANA to exchange data with NetEpi. The traditional approach >> is to look at the HL7 specifications, work out which message types and >> message segments are most appropriate, and for the developers of each of >> the applications to add the ability to emit and consume HL7 messages >> which are compliant with the relevant aspects and parts of the HL7 >> specification. Of course, the actually data items collected by SAHANA >> and NetEpi are quite volatile and dynamic (that is, the data which needs >> to be exchanged will change as a disaster or a disease outbreak develops >> and unfolds), and HL7 v2.x does not handle changing data requirements >> very nicely at all. But alternative approaches are possible. For >> example, as a NetEpi developer, I can download all the SAHANA source >> code, set up an instance of it, and write a plug-in module or code patch >> for SAHANA which will produce data in exactly the form that NetEpi >> requires - without all the overhead of pouring through 700 pages of HL7 >> v2.x specifications, then having to augment those specifications in any >> case, write up those augmented specifications, send them tot he SAHAN >> people and try to get them to implement them. Or I can write a NetEpi >> extension to directly access the underlying SAHANA database. Or both >> SAHANA and NetEpi can agree to use XML-RPC or some other simple >> mechanism to interchange data and to remotely cause specific actions to >> occur in each others' systems. >> >> Of course, the objection will be raised that it will take more resources >> to define and create such special-purpose interfaces than it would to >> use a "standard" HL7 interface. The problem is, as has been discussed, >> that HL7 v2.x is an insufficient standard in so many respects, and thus >> it may, in many circumstances, be harder and more resource intensive, >> even in the long-term, to use it than to ignore it. Also, health >> applications and information systems themselves are in a constant state >> of development and change (particularly open-source applications), and >> so ongoing maintenance of any interoperability mechanism, whether it >> involves HL7 or not, will be needed in any case. Finally, open-source >> health information systems, particularly those deployed in developing >> and transitional countries and those deployed in community settings as >> opposed to hospitals and large clinics, should not allow themselves to >> be dictated to by a "standard" which is primarily designed to help run >> large hospitals in rich countries. After all, there is not exactly a lot >> of evidence from rich countries that have adopted HL7 v2.x widely that >> it is a better solution than other approaches. There are so many stories >> of systems which are supposedly "HL7" compliant failing to interoperate >> properly, or only being able to interoperate after a lot of case-by-case >> and point-to-point effort and money is expended. Open-source health >> systems should only use what has been demonstrated to work well, and >> should feel free to explore alternatives to HL7. Remember, what matters >> is that patient care and public health is improved, not that systems are >> compliant with arbitrary information standards developed in rich >> countries to run their well-resourced hospitals. Let's not put the cart >> before the horse. >> >> OK, having said all that, what would be really fascinating is one or >> more case studies in which interoperability between two or more >> open-source health information systems was implemented using a >> traditional, HL7 v2.x approach, and in parallel was implemented using a >> more ad hoc, light-weight approach (or approaches). Costs, time, ease of >> implementation and reliability and utility of the resulting >> interoperability could be compared. >> >> Finally, I should add that in my work in public health surveillance, we >> do use HL7 v2.x. That is why I am aware of the issues I have outlined >> above. In developed countries like Australia, there is little choice but >> to use HL7 v2.x. But in other settings where financial resources for >> health care are far less, please do consider alternatives, even if they >> are only temporary while waiting for HL7 v3.x and openEHR to be finished >> and become easy to use and well-supported. >> >> Tim C >> >> >>> -----Original Message----- >>> From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] >>> On Behalf Of lseldon@netspace.net.au >>> Sent: Wednesday, May 23, 2007 12:00 AM >>> To: foss_health@oshca.org >>> Subject: [FOSS_health] Re: interoperability >>> >>> Interoperability - Message standards >>> >>> Some people seem to be interested in pursuing this. >>> I have had more thoughts since my original proposal. >>> >>> The easiest path would be to go with HL7 v2.X. VistA already supports that >>> >> - >> >>> so >>> it could possibly be used as a "test engine". openMRS claims to have >>> implemented >>> HL7 messages, but I am having trouble pinpointing exactly how. I have >>> already >>> pointed to numerous tools for this standard. >>> >>> However, there is a problem. HL7 v2.X is "old technology" and even the >>> standards-makers are moving to XML. Therefore, OSHCA and FOSS should >>> >> really >> >>> also >>> move to XML. >>> Note that openMRS uses XML rather extensively. Indeed, any application >>> >> based >> >>> on >>> Java, or more specifically J2EE, would almost automatically use XML. >>> >>> A compromise would be to use the XML wrappers for HL7 v2.3-2.5. Fairly >>> >> easy >> >>> - >>> just use one of the conversion tools for v2.X -> v2.X XML. Both VistA and >>> openMRS would have to adopt this (in addition to everybody else). >>> >>> Another option would be to use "native" XML and just agree on the >>> terminology >>> (elements). The common terminology would be derived from the mappings of >>> each >>> data structure to SNOMED, ICD-10, LOINC, ICPC2, CCR or whatever is agreed >>> on. >>> The Java-based applications should not have much difficulty with this, >>> >> once >> >>> the >>> data maps are aligned. (I have found that IndivoHealth, which seems to be >>> the >>> engine behind MyOSCAR, has also opted for XML-based data structures not >>> aligned >>> to any single standard.) >>> >>> I am sure somebody can think of other options. >>> It is up to the developers to agree on an option. >>> Lee >>> >>> >>> >>> ------------------------------------------------------------ >>> This email was sent from Netspace Webmail: http://www.netspace.net.au >>> >>> _______________________________________________ >>> FOSS_health mailing list >>> FOSS_health@oshca.org >>> http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >>> >>> >>> _______________________________________________ >>> FOSS_health mailing list >>> FOSS_health@oshca.org >>> http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >>> >> _______________________________________________ >> FOSS_health mailing list >> FOSS_health@oshca.org >> http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >> >> > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070524/ceca0baa/attachment.htm From davidhcchan at yahoo.com Fri May 25 10:58:40 2007 From: davidhcchan at yahoo.com (David Chan) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Research Question was:Conference Results Message-ID: <584373.41642.qm@web30503.mail.mud.yahoo.com> Cochrane Review is a systematic review of current evidence. We don't expect to find a lot of high quality comparative studies. We'll probably enlist the help of a good librarian to start. There is no funding attached to this - just volunteer time on the reviewers part. David David H Chan, MD, CCFP, MSc, FCFP Associate Professor Department of Family Medicine McMaster University ----- Original Message ---- From: Tim Cook To: foss_health@oshca.org Sent: Tuesday, May 22, 2007 3:21:27 PM Subject: Re: [FOSS_health] Research Question was:Conference Results On Tue, 2007-05-22 at 05:14 -0700, David Chan wrote: > Dr. Tomislav Svoboda, Dr. Alex Jadad, and I have previously submitted a registration application to Cochrane for this title: Review > of Advantages and Disadvantages of Open versus Close Source System Software > in health care related information technology solutions > We haven't started the work formally yet. It seems that if there is sufficient interest in this group, we should collaborate. > > David Hi David, That is a very broad research question. Can you detail your project (metrics, etc.) and maybe how you intend to fund such a project? Regards, Tim -- Timothy Cook, MSc Health Informatics Research Services http://home.comcast.net/~tw_cook/ 01-904-322-8582 _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health ____________________________________________________________________________________Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From davidhcchan at yahoo.com Fri May 25 10:59:39 2007 From: davidhcchan at yahoo.com (David Chan) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Research Question was:Conference Results Message-ID: <141107.42868.qm@web30506.mail.mud.yahoo.com> We haven't started the literature search yet. We have just turned in our application to the Cochrane Collaboration. David David H Chan, MD, CCFP, MSc, FCFP Associate Professor Department of Family Medicine McMaster University ----- Original Message ---- From: Nandalal Gunaratne To: foss_health@oshca.org Sent: Tuesday, May 22, 2007 9:43:23 PM Subject: Re: [FOSS_health] Research Question was:Conference Results How far have you gone on this? Any literature searches? Nanda --- David Chan wrote: > Dr. Tomislav Svoboda, Dr. Alex Jadad, and I have > previously submitted a registration application to > Cochrane for this title: Review > of Advantages and Disadvantages of Open versus > Close Source System Software > in health care related information technology > solutions > We haven't started the work formally yet. It seems > that if there is sufficient interest in this group, > we should collaborate. > > David > > > David H Chan, MD, CCFP, MSc, FCFP > Associate Professor > Department of Family Medicine > McMaster University > > ----- Original Message ---- > From: Luciana Tricai Cavalini > To: tw_cook@comcast.net; foss_health@oshca.org > Sent: Tuesday, May 22, 2007 8:42:32 AM > Subject: Re: [FOSS_health] Research Question > was:Conference Results > > Hello Tim, Tim and all, > > > > I'm sorry if I am being persistent, but I think we > should make some effort > in order to perform a formal systematic review (SR > from now on) after giving > up and shift to an expanded review. If we were > registered at Cochrane > Database (CochDb from now on), our searching for > evidence will be safely > stored and when the mission is accomplished, we are > supposed to be > acknowledged by the global scientific community. It > is not just a sort of > "label": I'm here talking about an empowering > strategy which can enrich the > results of our efforts. > > We can be audacious and purpose the inclusion of > "black" and "grey" > literature in our SR, according to Dr. Churches' > suggestion. This is a > challenge but it is a good one; I was thinking the > same way. Our subject has > some specificity that can't be ignored. This can > bring some resistance to > our CochDb registration but I think it is a good bet > and brings relative > originality to our project. > > Dr. Churches raised some methodological issues I was > thinking about last > night. What is our objective? Search for evidence on > FOSS solutions > efficacy/efficiency/effectiveness in health compared > to what? > > (1) FOSS x commercial solutions? That's > questionable; one can say that we > can be only comparing two inefficient interventions. > Probably this study > should be registered at CochDb only as an > econometric study (because the > only thing remaining is cost analysis). It is not > that bad at all; this is > important for decision-makers, and they are > obviously our clients. > > (2) FOSS x no IT intervention? In technical terms, > quasi-experimental > studies? This is closer to the ideal, but searching > for these studies is > probably an arid task. I suspect we will find sparse > studies designed this > way. By the way, I think we should ***prepare > ourselves to perform this kind > of study***. In other words: if the evidence doesn't > exist, we must build > it. But it requires strong collaborative work. > > I would like not to talk about which "official" > databases we could search > for in order to perform the SR first step, because, > both reviewers must > reach to an agreement on it, and ***it takes part of > the SR process***, thus > it means that ***must be documented*** at the > structured abstract; but these > are not the latest news down the square: Cochrane > Collaboration has defined > strict guidelines on it, all we have to do is to > follow them. > > > > (I think all this stuff can be arid for some of us, > but unfortunately > nowadays science may seem -but only seem - a kind of > strait jacket. The > problem is: we are well intentioned, but how many > are not? Think about > tobacco industry-sponsored studies during the > 1980's, and subscribed by some > of the most famous epidemiologists in the world, > stating that coffee, and > not cigarettes, was the real villain?) > > > > Best regards, > > > > Luciana. > > > > ----- Original Message ----- > From: "Tim Cook" > To: "FOSS Health" > Sent: Tuesday, May 22, 2007 4:11 AM > Subject: [FOSS_health] Research Question > was:Conference Results > > > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > > > > ____________________________________________________________________________________ > Park yourself in front of a world of choices in > alternative vehicles. Visit the Yahoo! Auto Green > Center. > http://autos.yahoo.com/green_center/ > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html From nandalalx at yahoo.com Fri May 25 22:41:22 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <200705242137.34358.christian.heller@tuxtax.de> Message-ID: <445353.94404.qm@web58706.mail.re1.yahoo.com> HXP was with the Care2x project and I am not sure if OSCAR was involved at all. I doubt it. Nandalal --- Christian Heller wrote: > Hello Lee, > > > Interoperability - Message standards > > > > Some people seem to be interested in pursuing > this. > > I have had more thoughts since my original > proposal. > [..] > > I do not have time to commit to the project, but > would like to give > my opinion, if possible. I vote for your proposal to > stick with XML. > > Also, I do not recommend using HL7 RIM3 since it is > a complex domain > model to be used in application frameworks for > building standalone > application systems, but not suitable for data > interchange. > HL7 CDA might be a better solution. > > OpenEHR is very complex and not mature in my eyes > (my opinion). > > HDTF (CORBAmed) is o.k. and might be faster than an > XML-based approach, > but brings with some overhead, needs IDL interfaces, > an ORB process > running etc. and not many programmers know about > CORBA any longer. > > I wonder what happened to HXP, in which OSCAR was > involved? > In my opinion, this is the way to go. Start simple > and get some > data exchanged via XML, as prototype solution. > Then think closely about the XML format and refine > it. > > You may also want to have a look at CYBOL, an > XML-based format > described here (DTD, XSD, EBNF): > http://cybop.berlios.de/cybol/index.html > > It has just four tags and four attributes and is > very flexible, > yet able to hold meta information (the third level > :-). > I just copy the DTD here: > > > > > > > name CDATA #REQUIRED > channel CDATA #REQUIRED > abstraction CDATA #REQUIRED > model CDATA #REQUIRED> > > name CDATA #REQUIRED > channel CDATA #REQUIRED > abstraction CDATA #REQUIRED > model CDATA #REQUIRED> > > name CDATA #REQUIRED > channel CDATA #REQUIRED > abstraction CDATA #REQUIRED > model CDATA #REQUIRED> > > Here are some example models: > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/cybop/examples/helloworld/greeting.cybol?rev=1.2&content-type=text/vnd.viewcvs-markup > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/cybop/examples/helloworld/startup.cybol?rev=1.10&content-type=text/vnd.viewcvs-markup > > Note, that "state models" (the first link being part > of a textual user > interface) and "logic models" (the second link > representing the startup > algorithm) are represented in the same way, as > opposed to traditional > programming languages having a different syntax for > structures/ classes > and methods/ functions/ procedures. > > Christian > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From nandalalx at yahoo.com Fri May 25 23:00:13 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <46564E51.2070704@wildmedic.org> Message-ID: <257537.73047.qm@web58701.mail.re1.yahoo.com> Yes, indeed. If we have one solution which works between a few FOSS apps from defined categories, that will create a FOSS ecology by itself. OpenMRS - for hospitals (witha laboratory/radiology management as well) OSCAR - Clinical Practice management (with Drugref) NetEpi and CHITS - for epidemiology or community health Sahana - Disaster Mangement System These work together to exchange patient and other data using a "simple but expandable and capable" XML based system. What a start! One of my favorite sayings which I keep repeating without apology, is by Albert Einstein "Keep everything as simple as possible, but not simpler" Nandalal --- Jel Coward wrote: > Tim C wrote: > > Don't get bogged down trying to solve generalised > future > > interoperability problems. Solve specific > interoperability problems now > > instead. > > > > Yes, yes and yes. > > Do it now. Organise it later. > > So many things die from frustration as the perceived > need to build to the > big pictures sucks them into the swamp. > > It is a bit like using an avalanche transceiver. > There are described > search patterns to use and learn, and much science. > But the best piece of > advice I ever received when using one was, if it > isn't clear what is going > on - just move, and move quickly - things then start > to become clear. > > Jel Coward > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > ____________________________________________________________________________________Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php From Karsten.Hilbert at gmx.net Fri May 25 23:09:58 2007 From: Karsten.Hilbert at gmx.net (Karsten Hilbert) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <257537.73047.qm@web58701.mail.re1.yahoo.com> References: <46564E51.2070704@wildmedic.org> <257537.73047.qm@web58701.mail.re1.yahoo.com> Message-ID: <20070525150958.GB3963@merkur.hilbert.loc> On Fri, May 25, 2007 at 08:00:13AM -0700, Nandalal Gunaratne wrote: > Yes, indeed. If we have one solution which works > between a few FOSS apps from defined categories, that > will create a FOSS ecology by itself. > > OpenMRS - for hospitals (witha laboratory/radiology > management as well) > OSCAR - Clinical Practice management (with Drugref) > NetEpi and CHITS - for epidemiology or community > health > Sahana - Disaster Mangement System > > These work together to exchange patient and other data > using a "simple but expandable and capable" XML based > system. If this gets off the ground GNUmed will be happy to participate in a Tim-like keep-it-pragmatic approach. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 From dalmolin at e-cology.ca Fri May 25 23:22:31 2007 From: dalmolin at e-cology.ca (Joseph Dal Molin) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <257537.73047.qm@web58701.mail.re1.yahoo.com> References: <257537.73047.qm@web58701.mail.re1.yahoo.com> Message-ID: <4656FF37.3060403@e-cology.ca> Nadalal ... the market will define the ecology.... it's simple economics and resource allocation. Few if any of the projects have the time to spend on integration unless there is a project which brings them together in a practical context. J. Nandalal Gunaratne wrote: > Yes, indeed. If we have one solution which works > between a few FOSS apps from defined categories, that > will create a FOSS ecology by itself. > > OpenMRS - for hospitals (witha laboratory/radiology > management as well) > OSCAR - Clinical Practice management (with Drugref) > NetEpi and CHITS - for epidemiology or community > health > Sahana - Disaster Mangement System > > > These work together to exchange patient and other data > using a "simple but expandable and capable" XML based > system. > > What a start! > > One of my favorite sayings which I keep repeating > without apology, is by Albert Einstein > > "Keep everything as simple as possible, but not > simpler" > > Nandalal > > > --- Jel Coward wrote: > >> Tim C wrote: >>> Don't get bogged down trying to solve generalised >> future >>> interoperability problems. Solve specific >> interoperability problems now >>> instead. >>> >> Yes, yes and yes. >> >> Do it now. Organise it later. >> >> So many things die from frustration as the perceived >> need to build to the >> big pictures sucks them into the swamp. >> >> It is a bit like using an avalanche transceiver. >> There are described >> search patterns to use and learn, and much science. >> But the best piece of >> advice I ever received when using one was, if it >> isn't clear what is going >> on - just move, and move quickly - things then start >> to become clear. >> >> Jel Coward >> _______________________________________________ >> FOSS_health mailing list >> FOSS_health@oshca.org >> > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > > ____________________________________________________________________________________Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. > http://new.toolbar.yahoo.com/toolbar/features/mail/index.php > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > . > From william at amh.org.bh Sat May 26 16:18:32 2007 From: william at amh.org.bh (William D. Lauesen) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] HIMSS Asia Pac '07 References: <257537.73047.qm@web58701.mail.re1.yahoo.com> <4656FF37.3060403@e-cology.ca> Message-ID: <029101c79f6e$736f2030$4b010ac0@amh.org> Here is a brief report on the HIMSS Asia Pacific 2007 conference, the first, in Singapore the week after the OSHCA conference. It was a larger conference on IT in the healthcare field, co-sponsored by a couple of dozen Asia Pacific organizations. (The Healthcare Information and Management Systems Society is the main healthcare IT organization in the US, and now also has a Europe branch. See http://www.himss.org/ and http://emea.himss.org/ for Europe.) As far as I noticed, there were only two people at both the OSHCA and HIMSS AsiaPac conferences: myself and Dr. Goh Hsien Ming, the head of the Asia Pacific Assoc. for Medical Informatics. You may remember that he led the "debate" on proprietary vs. open source software that we had, with his introductory presentation, which he also gave as the last after-closing session at the HIMSS conference. His presentation was the only one I attended (there were multiple tracks) that mentioned open source at all, unfortunately including a couple by Malasia Ministry of Health speakers. (I did ask a question about open source software use from one of the Malaysia MoH speakers. Although he did challenge vendors to come up with suitable solutions as they were going to be spending money on new solutions, and mentioned their funding limitations, he didn't mention open source at all. When I asked him the question, he made it sound like they use open source a lot, but didn't elaborate at all.) Unfortunately, FOSS had almost no visibility. It was interesting to hear about IHE "Integrating the Healthcare Enterprise" ( http://www.ihe.net/ ) and the HIMSS Interoperability Showcase ( http://www.interoperabilityshowcase.org/ ) in the US. There were some talks about IHE in their booth at the adjoining exhibition (but there was no Interoperability Showcase in Singapore). Perhaps if OSHCA could demonstrate interoperability of some FOSS products at one of their big showcases it would be a good opportunity to showcase FOSS and its advantages to a wider audience. They did mention that the next HIMSS AsiaPac will be in Hong Kong on May 20-23, 2008. (The organizer said that they are considering KL for 2009.) Having our conference in conjunction with another larger healthcare IT conference like this one - whether in SE Asia or elsewhere - would have its advantages. William This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070526/7375dc32/attachment.html From drcheah at pc.jaring.my Sun May 27 10:45:21 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] WHO Call for Papers: Towards a scaling-up of training and education for health workers Message-ID: <4658F0C1.4040100@pc.jaring.my> [Forwarded from HCW Discussion List: listserv.critpath.org/archives/index.html] CALL FOR PAPERS WHO and the journals Education for Health and Human Resources for Health are now accepting papers for joint special issues addressing the critical need for a skilled, sustainable health workforce in the developing world. Submitted articles must fall under the broad theme: Towards a scaling-up of training and education for health workers. The World Health Report 2006, 'Working together for health', recognized the centrality of the health workforce for the effective operation of country health systems and outlined proposals to tackle a global shortage of 4.3 million health workers. There is increasing evidence that that this shortage is interfering with efforts to achieve international development goals, including those contained in the Millennium Declaration and those of WHO's priority programmes. The health workforce crisis in developing countries derives principally from inadequate educational opportunities for health workers and a lack of relevance of their training to community health care practice. Additional contributing factors include: inadequate compensation and working conditions, the deteriorating health of the workforce in many developing countries, urban/rural and workforce imbalance, and migration of the workforce from developing to developed countries. We are seeking manuscripts which concern the scaling-up of training and education for health workers. Possible sub-themes include, but are not limited to: - private sector engagement - regulatory frameworks for education and practice - labour market dynamics after the production of health workers (e.g. retention) - training teams rather than individuals - skills mix - multi-skilled workers, responsive to exiting needs - task-shifting / role substitution - competency-based education and training Examples of questions that could be considered are: - What ongoing efforts to increase graduate level primary care training have been established in developing countries. What has been their impact and what have been their problems? - What effective strategies have been developed and tested for customizing the workforce skill mix to local health service needs? For example, what impact have recent health sector reforms had on the local health workforce? - What is the status of existing efforts to train health workers using innovative methods, including distance learning and various forms of information technology? How will training by protocol differ from, and complement, traditional community health worker training? - How can the health professional training be better aligned with local health needs and be more socially accountable? - What is the status of existing collaborations between developing countries aiming to improve health worker education? - How have modifications in healthcare management had an impact upon health workforce capacity at the local level? Papers will be accepted in two formats: - Full papers of 3000 words or less for policy and research papers - Brief communications of less than 1200 words: better suited to program or project descriptions or commentaries. Planned publication is over the period from June to August 2008. There will be an online facility to respond to published articles in order to accommodate a live debate. If you would like to submit either an article or brief, please send us a provisional title and a short outline of the major topics you would address. Proposals for manuscripts are due by 31 July 2007 and should be submitted by e-mail to hrhspecial@who.int. Instructions for submission of articles will then be provided with feedback. Final manuscripts are due by 30 October 2007. ************************************************* From amidgley2 at defoam.net Mon May 28 06:29:10 2007 From: amidgley2 at defoam.net (Adrian Midgley) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <7bb0495c0705241411x7d27b465yf119f7c69f5e2489@mail.gmail.com> References: <20070524144435.BTB60591@thymus.msis.med.umich.edu> <4655e166.158e37f3.5cfd.ffffa49dSMTPIN_ADDED@mx.google.com> <7bb0495c0705241411x7d27b465yf119f7c69f5e2489@mail.gmail.com> Message-ID: <465A0636.1080203@defoam.net> Tim C wrote: > On 25/05/07, *Tom Jones* > wrote: > > I think that the hub and spoke approach is more efficient than > proliferating > point to point approaches > > > Yes, that is the received wisdom, but I question whether it is > actually the case, I think if several groups are trying to connect _in the same time period_ then a lingua franca or even hub and spoke arrangement is more likely to arise and is clearly better. http://www.defoam.net/writing/4xn.gif Given that, new arrivals coming one at a time should find it is cheaper to join that, particularly if the lower layers of protocols and components are FLOSS rather than proprietary, or at least are published and gratuit to use. However if two orgs need to swap info, they are likely to see a bilateral special purpose link as cheaper, and they are right. So later you end up with http://www.defoam.net/writing/4x2.gif From tim.churches at gmail.com Mon May 28 07:00:25 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <465A0636.1080203@defoam.net> References: <20070524144435.BTB60591@thymus.msis.med.umich.edu> <4655e166.158e37f3.5cfd.ffffa49dSMTPIN_ADDED@mx.google.com> <7bb0495c0705241411x7d27b465yf119f7c69f5e2489@mail.gmail.com> <465A0636.1080203@defoam.net> Message-ID: <7bb0495c0705271600v4bf2393ese3c6a6779493c545@mail.gmail.com> On 28/05/07, Adrian Midgley wrote: > > Tim C wrote: > > On 25/05/07, *Tom Jones* > > wrote: > > > > I think that the hub and spoke approach is more efficient than > > proliferating > > point to point approaches > > > > > > Yes, that is the received wisdom, but I question whether it is > > actually the case, > > I think if several groups are trying to connect _in the same time > period_ then a lingua franca or even hub and spoke arrangement is more > likely to arise and is clearly better. > http://www.defoam.net/writing/4xn.gif > > Given that, new arrivals coming one at a time should find it is cheaper > to join that, particularly if the lower layers of protocols and > components are FLOSS rather than proprietary, or at least are published > and gratuit to use. > > However if two orgs need to swap info, they are likely to see a > bilateral special purpose link as cheaper, and they are right. > So later you end up with http://www.defoam.net/writing/4x2.gif In practice, with HL7 v2.x it tends to go like this: http://members.optusnet.com.au/tchur/interchange.png That is, everyone starts out with what is essentially a point-to-point interface via a shared message routing hub. Everyone pretends that they are using a shared format, but in fact they are not to any great degree. later, a shared format may emerge and everyone endeavours to emit their messages into that format, but usually additional transformation is still required in the hub. The alternative strategy is to spend a decade or more working on a much more intellectually pleasing solution, as in openEHR or perhaps HL7 v3.x. The problem is that it is a hard nut to crack, perhaps too hard, and people need to get on with exchanging data in the meantime. Tim C -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070528/123d7e06/attachment.htm From tom.jones at tolvenhealth.com Mon May 28 07:19:05 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <7bb0495c0705271600v4bf2393ese3c6a6779493c545@mail.gmail.com> Message-ID: I have heard that dichotomy characterized as the group that "is too busy to put the steering wheel on the car and is continuing to apply pressure to the gas pedal" and the group that says "stop the car, we need to design a steering wheel". The HL7 movement appears to be large enough to contain both groups! The steering wheel design people are heads down in the RIM, CDA, CCD etc. and the busy group is churning out more layers of stuff in HL7 v2.n _____ From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of Tim C Sent: Sunday, May 27, 2007 4:00 PM To: amidgley@defoam.net; foss_health@oshca.org Subject: Re: [FOSS_health] Re: interoperability On 28/05/07, Adrian Midgley wrote: Tim C wrote: > On 25/05/07, *Tom Jones* > wrote: > > I think that the hub and spoke approach is more efficient than > proliferating > point to point approaches > > > Yes, that is the received wisdom, but I question whether it is > actually the case, I think if several groups are trying to connect _in the same time period_ then a lingua franca or even hub and spoke arrangement is more likely to arise and is clearly better. http://www.defoam.net/writing/4xn.gif Given that, new arrivals coming one at a time should find it is cheaper to join that, particularly if the lower layers of protocols and components are FLOSS rather than proprietary, or at least are published and gratuit to use. However if two orgs need to swap info, they are likely to see a bilateral special purpose link as cheaper, and they are right. So later you end up with http://www.defoam.net/writing/4x2.gif In practice, with HL7 v2.x it tends to go like this: http://members.optusnet.com.au/tchur/interchange.png That is, everyone starts out with what is essentially a point-to-point interface via a shared message routing hub. Everyone pretends that they are using a shared format, but in fact they are not to any great degree. later, a shared format may emerge and everyone endeavours to emit their messages into that format, but usually additional transformation is still required in the hub. The alternative strategy is to spend a decade or more working on a much more intellectually pleasing solution, as in openEHR or perhaps HL7 v3.x. The problem is that it is a hard nut to crack, perhaps too hard, and people need to get on with exchanging data in the meantime. Tim C -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070527/02acf49d/attachment.html From forslund at mail.com Mon May 28 07:32:02 2007 From: forslund at mail.com (David Forslund) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <7bb0495c0705271600v4bf2393ese3c6a6779493c545@mail.gmail.com> References: <20070524144435.BTB60591@thymus.msis.med.umich.edu> <4655e166.158e37f3.5cfd.ffffa49dSMTPIN_ADDED@mx.google.com> <7bb0495c0705241411x7d27b465yf119f7c69f5e2489@mail.gmail.com> <465A0636.1080203@defoam.net> <7bb0495c0705271600v4bf2393ese3c6a6779493c545@mail.gmail.com> Message-ID: <465A14F2.7010502@mail.com> I believe the "intellectually pleasing" approach was accomplished almost a decade ago (or more) but no one seems to understand it or care, which is too bad. "emitting messages" is a fairly archaic and "assembly language" approach to the problem which keeps software engineers busy but does little to "solve" the problem. Distributed services and standards for them have been around a long time, and people are just starting to understand their value and power. I think they actually simplify the problem considerably, but I appear to be a minority. There are standard mechanisms for discovering what services are available and their capabilities, so that one can connect to a distributed service or a point to point service with equal ease. This is all old stuff that seems to need to be reinvented about every 10 years or so. This is good for full employment of software engineers, but not for any benefit to a healthcare consumer. Dave Tim C wrote: > On 28/05/07, *Adrian Midgley* > wrote: > > Tim C wrote: > > On 25/05/07, *Tom Jones* > > >> wrote: > > > > I think that the hub and spoke approach is more efficient than > > proliferating > > point to point approaches > > > > > > Yes, that is the received wisdom, but I question whether it is > > actually the case, > > I think if several groups are trying to connect _in the same time > period_ then a lingua franca or even hub and spoke arrangement is more > likely to arise and is clearly better. > http://www.defoam.net/writing/4xn.gif > > Given that, new arrivals coming one at a time should find it is > cheaper > to join that, particularly if the lower layers of protocols and > components are FLOSS rather than proprietary, or at least are > published > and gratuit to use. > > However if two orgs need to swap info, they are likely to see a > bilateral special purpose link as cheaper, and they are right. > So later you end up with http://www.defoam.net/writing/4x2.gif > > > In practice, with HL7 v2.x it tends to go like this: > http://members.optusnet.com.au/tchur/interchange.png > > > That is, everyone starts out with what is essentially a point-to-point > interface via a shared message routing hub. Everyone pretends that > they are using a shared format, but in fact they are not to any great > degree. later, a shared format may emerge and everyone endeavours to > emit their messages into that format, but usually additional > transformation is still required in the hub. > > The alternative strategy is to spend a decade or more working on a > much more intellectually pleasing solution, as in openEHR or perhaps > HL7 v3.x. The problem is that it is a hard nut to crack, perhaps too > hard, and people need to get on with exchanging data in the meantime. > > Tim C > > ------------------------------------------------------------------------ > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > From Klaus at Veil.net.au Mon May 28 07:35:59 2007 From: Klaus at Veil.net.au (Klaus D Veil) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <465A14F2.7010502@mail.com> Message-ID: <003e01c7a0b7$ca611d90$2100a8c0@acerkv> David, Do you want to share more details on the "distributed services for healthcare" that you are referring to? Klaus -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of David Forslund Sent: Monday, 28 May 2007 09:32 To: foss_health@oshca.org Subject: Re: [FOSS_health] Re: interoperability I believe the "intellectually pleasing" approach was accomplished almost a decade ago (or more) but no one seems to understand it or care, which is too bad. "emitting messages" is a fairly archaic and "assembly language" approach to the problem which keeps software engineers busy but does little to "solve" the problem. Distributed services and standards for them have been around a long time, and people are just starting to understand their value and power. I think they actually simplify the problem considerably, but I appear to be a minority. There are standard mechanisms for discovering what services are available and their capabilities, so that one can connect to a distributed service or a point to point service with equal ease. This is all old stuff that seems to need to be reinvented about every 10 years or so. This is good for full employment of software engineers, but not for any benefit to a healthcare consumer. Dave Tim C wrote: > On 28/05/07, *Adrian Midgley* > wrote: > > Tim C wrote: > > On 25/05/07, *Tom Jones* > > >> wrote: > > > > I think that the hub and spoke approach is more efficient than > > proliferating > > point to point approaches > > > > > > Yes, that is the received wisdom, but I question whether it is > > actually the case, > > I think if several groups are trying to connect _in the same time > period_ then a lingua franca or even hub and spoke arrangement is more > likely to arise and is clearly better. > http://www.defoam.net/writing/4xn.gif > > Given that, new arrivals coming one at a time should find it is > cheaper > to join that, particularly if the lower layers of protocols and > components are FLOSS rather than proprietary, or at least are > published > and gratuit to use. > > However if two orgs need to swap info, they are likely to see a > bilateral special purpose link as cheaper, and they are right. > So later you end up with http://www.defoam.net/writing/4x2.gif > > > In practice, with HL7 v2.x it tends to go like this: > http://members.optusnet.com.au/tchur/interchange.png > > > That is, everyone starts out with what is essentially a point-to-point > interface via a shared message routing hub. Everyone pretends that > they are using a shared format, but in fact they are not to any great > degree. later, a shared format may emerge and everyone endeavours to > emit their messages into that format, but usually additional > transformation is still required in the hub. > > The alternative strategy is to spend a decade or more working on a > much more intellectually pleasing solution, as in openEHR or perhaps > HL7 v3.x. The problem is that it is a hard nut to crack, perhaps too > hard, and people need to get on with exchanging data in the meantime. > > Tim C > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From forslund at mail.com Mon May 28 08:53:04 2007 From: forslund at mail.com (David Forslund) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <003e01c7a0b7$ca611d90$2100a8c0@acerkv> References: <003e01c7a0b7$ca611d90$2100a8c0@acerkv> Message-ID: <465A27F0.5000602@mail.com> Check out http://healthcare.omg.org and http://OpenEMed.org. OpenEMed.org implements most of the OMG HDTF specifications from the late 90s and early 2000's all in open source. These are service-oriented specifications specifically designed for interoperability and demonstrated to work. The OMG HDTF is working as a joint effort with HL7 to update these specifications to current popular technologies and to increase their capabilities. You can read more about this work at http://hssp.wikispaces.org. It is an open process and, in my opinion, should be participated in by those in the FOSS community that are interested in interoperability. Participating in this process would ensure that open source solutions would be able to interoperate with commercial products, this increasing their penetration into the broad healthcare market. For many on this list, they've heard this from me before. There are some participants in the HSSP effort from the open source community, but there should be more and it provides some interesting targets for demonstrating true interoperability. Dave Klaus D Veil wrote: > David, > > Do you want to share more details on the "distributed services for > healthcare" that you are referring to? > > Klaus > > -----Original Message----- > From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] > On Behalf Of David Forslund > Sent: Monday, 28 May 2007 09:32 > To: foss_health@oshca.org > Subject: Re: [FOSS_health] Re: interoperability > > I believe the "intellectually pleasing" approach was accomplished almost a > decade ago (or more) but no one seems to understand it or care, which is too > bad. "emitting messages" is a fairly archaic and "assembly language" > approach to the problem which keeps software engineers busy but does little > to "solve" the problem. Distributed services and standards for them have > been around a long time, and people are just > starting to understand their value and power. I think they actually > simplify the problem considerably, but I appear to be a minority. There are > standard mechanisms for discovering what services are available and their > capabilities, so that one can connect to a distributed service or a point to > point service with equal ease. This is all old stuff that seems to need to > be reinvented about every 10 years or so. This is good for full employment > of software engineers, but not for any benefit to a healthcare consumer. > > Dave > Tim C wrote: > >> On 28/05/07, *Adrian Midgley* > > wrote: >> >> Tim C wrote: >> > On 25/05/07, *Tom Jones* > >> > > >> wrote: >> > >> > I think that the hub and spoke approach is more efficient than >> > proliferating >> > point to point approaches >> > >> > >> > Yes, that is the received wisdom, but I question whether it is >> > actually the case, >> >> I think if several groups are trying to connect _in the same time >> period_ then a lingua franca or even hub and spoke arrangement is more >> likely to arise and is clearly better. >> http://www.defoam.net/writing/4xn.gif >> >> Given that, new arrivals coming one at a time should find it is >> cheaper >> to join that, particularly if the lower layers of protocols and >> components are FLOSS rather than proprietary, or at least are >> published >> and gratuit to use. >> >> However if two orgs need to swap info, they are likely to see a >> bilateral special purpose link as cheaper, and they are right. >> So later you end up with http://www.defoam.net/writing/4x2.gif >> >> >> In practice, with HL7 v2.x it tends to go like this: >> http://members.optusnet.com.au/tchur/interchange.png >> >> >> That is, everyone starts out with what is essentially a point-to-point >> interface via a shared message routing hub. Everyone pretends that >> they are using a shared format, but in fact they are not to any great >> degree. later, a shared format may emerge and everyone endeavours to >> emit their messages into that format, but usually additional >> transformation is still required in the hub. >> >> The alternative strategy is to spend a decade or more working on a >> much more intellectually pleasing solution, as in openEHR or perhaps >> HL7 v3.x. The problem is that it is a hard nut to crack, perhaps too >> hard, and people need to get on with exchanging data in the meantime. >> >> Tim C >> >> ---------------------------------------------------------------------- >> -- >> From Klaus at Veil.net.au Mon May 28 08:58:48 2007 From: Klaus at Veil.net.au (Klaus D Veil) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <465A27F0.5000602@mail.com> Message-ID: <00cd01c7a0c3$5cb8a4a0$2100a8c0@acerkv> Yes, the HSSP work (a collaboration of HL7 and OMG) has been very productive and produced results in a very impressive time-frame. I would encourage members in the FOSS community to review the materials on the Wiki and consider participating if possible. Klaus -----Original Message----- From: David Forslund [mailto:forslund@mail.com] Sent: Monday, 28 May 2007 10:53 To: Klaus@Veil.net.au; foss_health@oshca.org Subject: Re: [FOSS_health] Re: interoperability Check out http://healthcare.omg.org and http://OpenEMed.org. OpenEMed.org implements most of the OMG HDTF specifications from the late 90s and early 2000's all in open source. These are service-oriented specifications specifically designed for interoperability and demonstrated to work. The OMG HDTF is working as a joint effort with HL7 to update these specifications to current popular technologies and to increase their capabilities. You can read more about this work at http://hssp.wikispaces.org. It is an open process and, in my opinion, should be participated in by those in the FOSS community that are interested in interoperability. Participating in this process would ensure that open source solutions would be able to interoperate with commercial products, this increasing their penetration into the broad healthcare market. For many on this list, they've heard this from me before. There are some participants in the HSSP effort from the open source community, but there should be more and it provides some interesting targets for demonstrating true interoperability. Dave Klaus D Veil wrote: > David, > > Do you want to share more details on the "distributed services for > healthcare" that you are referring to? > > Klaus > > -----Original Message----- > From: foss_health-bounces@oshca.org > [mailto:foss_health-bounces@oshca.org] > On Behalf Of David Forslund > Sent: Monday, 28 May 2007 09:32 > To: foss_health@oshca.org > Subject: Re: [FOSS_health] Re: interoperability > > I believe the "intellectually pleasing" approach was accomplished > almost a decade ago (or more) but no one seems to understand it or > care, which is too bad. "emitting messages" is a fairly archaic and "assembly language" > approach to the problem which keeps software engineers busy but does > little to "solve" the problem. Distributed services and standards for > them have been around a long time, and people are just > starting to understand their value and power. I think they actually > simplify the problem considerably, but I appear to be a minority. > There are standard mechanisms for discovering what services are > available and their capabilities, so that one can connect to a > distributed service or a point to point service with equal ease. This > is all old stuff that seems to need to be reinvented about every 10 > years or so. This is good for full employment of software engineers, but not for any benefit to a healthcare consumer. > > Dave > Tim C wrote: > >> On 28/05/07, *Adrian Midgley* > > wrote: >> >> Tim C wrote: >> > On 25/05/07, *Tom Jones* > >> > > >> wrote: >> > >> > I think that the hub and spoke approach is more efficient than >> > proliferating >> > point to point approaches >> > >> > >> > Yes, that is the received wisdom, but I question whether it is >> > actually the case, >> >> I think if several groups are trying to connect _in the same time >> period_ then a lingua franca or even hub and spoke arrangement is more >> likely to arise and is clearly better. >> http://www.defoam.net/writing/4xn.gif >> >> Given that, new arrivals coming one at a time should find it is >> cheaper >> to join that, particularly if the lower layers of protocols and >> components are FLOSS rather than proprietary, or at least are >> published >> and gratuit to use. >> >> However if two orgs need to swap info, they are likely to see a >> bilateral special purpose link as cheaper, and they are right. >> So later you end up with http://www.defoam.net/writing/4x2.gif >> >> >> In practice, with HL7 v2.x it tends to go like this: >> http://members.optusnet.com.au/tchur/interchange.png >> >> >> That is, everyone starts out with what is essentially a >> point-to-point interface via a shared message routing hub. Everyone >> pretends that they are using a shared format, but in fact they are >> not to any great degree. later, a shared format may emerge and >> everyone endeavours to emit their messages into that format, but >> usually additional transformation is still required in the hub. >> >> The alternative strategy is to spend a decade or more working on a >> much more intellectually pleasing solution, as in openEHR or perhaps >> HL7 v3.x. The problem is that it is a hard nut to crack, perhaps too >> hard, and people need to get on with exchanging data in the meantime. >> >> Tim C >> >> --------------------------------------------------------------------- >> - >> -- >> From drcheah at pc.jaring.my Mon May 28 09:52:12 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability - OSHCA context In-Reply-To: <00cd01c7a0c3$5cb8a4a0$2100a8c0@acerkv> References: <00cd01c7a0c3$5cb8a4a0$2100a8c0@acerkv> Message-ID: <465A35CC.30208@pc.jaring.my> General discussions on interoperability will always bring about varied views on approaches and different levels of interoperability. This discussion on FOSS_health@oshca.org arise from the recent OSHCA Conference 2007 where the theme is: "Moving the FOSS Agenda for Health: Setting the Framework for Interoperability". That does not mean that these discussions would not touch on interoperability between FOSS and proprietary solutions or other past initiatives. It was unfortunate that David, Klaus and Thomas Beale were not able to be at the conference. Tim Cook had a presentation on OpenEHR during the conference. Perhaps he would like to comment on the content of his presentation that could contribute toward the interoperability issues. The conference provided the platform to bring to the participants reviews on FOSS technologies, issues, applications so that OSHCA can better prepare to coordinate efforts by its members to collaborate to exchange data/information between and among current FOSS applications. Though OSHCA is mindful of other efforts, both in open source and proprietary environments, OSHCA will focus on efforts that will meet its Vision and Missions. OSHCA's immediate focus resulting from the conference will be a re-submission of its proposal for a collaborative grant on interoperability. This is only a small component (preparatory phase - phase 2) with definitive deliverables within a 6-month period. The 3rd phase will then deal with actual transfer of data/information amongst FOSS applications in test beds. Only projects funded through OSHCA's funding initiatives will be co-ordinated by OSHCA. OSHCA encourages and welcomes other initiatives and their presentations at future OSHCA conferences/workshops. One upcoming opportunity is the GK3 conference from Dec 11-13 2007 in Kuala Lumpur. See http://www.globalknowledge.org web-site. Many of these discussions may form the content for the methodology of the grant proposal, while others will be referenced in the proposal, either for phase 2 or phase 3 project. I take the opportunity to copy this e-mail to Thomas and the participants list for those who had not subscribed to FOSS_health@oshca.org to participate in discussions on interoperability. Rgds, Molly Klaus D Veil wrote: >Yes, the HSSP work (a collaboration of HL7 and OMG) has been very productive >and produced results in a very impressive time-frame. > >I would encourage members in the FOSS community to review the materials on >the Wiki and consider participating if possible. > >Klaus > >-----Original Message----- >From: David Forslund [mailto:forslund@mail.com] >Sent: Monday, 28 May 2007 10:53 >To: Klaus@Veil.net.au; foss_health@oshca.org >Subject: Re: [FOSS_health] Re: interoperability > >Check out http://healthcare.omg.org and http://OpenEMed.org. >OpenEMed.org implements most of the OMG HDTF specifications from the >late 90s and early 2000's all in open source. These are >service-oriented specifications specifically designed for interoperability >and demonstrated to work. The OMG HDTF is working as a joint effort with >HL7 to update these specifications to current popular technologies and to >increase their capabilities. You can read more about this work at >http://hssp.wikispaces.org. It is an open process and, in my opinion, >should be participated in by those in the FOSS >community that are interested in interoperability. Participating in >this process would ensure that open source solutions would be able to >interoperate with commercial products, this increasing their penetration >into the broad healthcare market. For many on this list, they've heard this >from me before. There are some participants in the HSSP effort from the >open source community, but there should be more and it provides some >interesting targets for demonstrating true interoperability. > >Dave > >Klaus D Veil wrote: > > >>David, >> >>Do you want to share more details on the "distributed services for >>healthcare" that you are referring to? >> >>Klaus >> >>-----Original Message----- >>From: foss_health-bounces@oshca.org >>[mailto:foss_health-bounces@oshca.org] >>On Behalf Of David Forslund >>Sent: Monday, 28 May 2007 09:32 >>To: foss_health@oshca.org >>Subject: Re: [FOSS_health] Re: interoperability >> >>I believe the "intellectually pleasing" approach was accomplished >>almost a decade ago (or more) but no one seems to understand it or >>care, which is too bad. "emitting messages" is a fairly archaic and >> >> >"assembly language" > > >>approach to the problem which keeps software engineers busy but does >>little to "solve" the problem. Distributed services and standards for >>them have been around a long time, and people are just >>starting to understand their value and power. I think they actually >>simplify the problem considerably, but I appear to be a minority. >>There are standard mechanisms for discovering what services are >>available and their capabilities, so that one can connect to a >>distributed service or a point to point service with equal ease. This >>is all old stuff that seems to need to be reinvented about every 10 >>years or so. This is good for full employment of software engineers, but >> >> >not for any benefit to a healthcare consumer. > > >>Dave >>Tim C wrote: >> >> >> >>>On 28/05/07, *Adrian Midgley* >>> wrote: >>> >>> Tim C wrote: >>> > On 25/05/07, *Tom Jones* >> >>> > >> >> wrote: >>> > >>> > I think that the hub and spoke approach is more efficient than >>> > proliferating >>> > point to point approaches >>> > >>> > >>> > Yes, that is the received wisdom, but I question whether it is >>> > actually the case, >>> >>> I think if several groups are trying to connect _in the same time >>> period_ then a lingua franca or even hub and spoke arrangement is >>> >>> >more > > >>> likely to arise and is clearly better. >>> http://www.defoam.net/writing/4xn.gif >>> >>> Given that, new arrivals coming one at a time should find it is >>> cheaper >>> to join that, particularly if the lower layers of protocols and >>> components are FLOSS rather than proprietary, or at least are >>> published >>> and gratuit to use. >>> >>> However if two orgs need to swap info, they are likely to see a >>> bilateral special purpose link as cheaper, and they are right. >>> So later you end up with http://www.defoam.net/writing/4x2.gif >>> >>> >>>In practice, with HL7 v2.x it tends to go like this: >>>http://members.optusnet.com.au/tchur/interchange.png >>> >>> >>>That is, everyone starts out with what is essentially a >>>point-to-point interface via a shared message routing hub. Everyone >>>pretends that they are using a shared format, but in fact they are >>>not to any great degree. later, a shared format may emerge and >>>everyone endeavours to emit their messages into that format, but >>>usually additional transformation is still required in the hub. >>> >>>The alternative strategy is to spend a decade or more working on a >>>much more intellectually pleasing solution, as in openEHR or perhaps >>>HL7 v3.x. The problem is that it is a hard nut to crack, perhaps too >>>hard, and people need to get on with exchanging data in the meantime. >>> >>>Tim C >>> >>>--------------------------------------------------------------------- >>>- >>>-- >>> >>> >>> > >_______________________________________________ >FOSS_health mailing list >FOSS_health@oshca.org >http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > From farhad at icddrb.org Mon May 28 12:16:07 2007 From: farhad at icddrb.org (Farhad Hussain) Date: Sun Jan 27 17:55:24 2008 Subject: [participants] Re: [FOSS_health] Re: interoperability - OSHCAcontext In-Reply-To: <465A35CC.30208@pc.jaring.my> References: <00cd01c7a0c3$5cb8a4a0$2100a8c0@acerkv> <465A35CC.30208@pc.jaring.my> Message-ID: Warm regards from Bangladesh. In the healthcare sector of Bangladesh computerization is in very early stage. Only big private hospitals in the capital city Dhaka are computerized. But these information systems are not talking with each other. Public hospitals are far from using Information Technology. In this scenario I would like to organize a community of IT and healthcare professionals to develop healthcare information systems using FOSS. Keeping OSHCA in mind I think that the community can actually represent local chapter of OSHCA. After forming the community we would like to develop a project proposal for submission to OSHCA in December, 2007. Look forward to receiving your comments, suggesstions and advice in this regard. Thanking You. Mohammad Farhad Hussain Manager, Computer Information Services Unit International Centre for Diarrhoeal Disease Research, Bangladesh (ICDDR,B) Mohakhali, Dhaka - 1212, Bangladesh. Phone: 880-2-8860523-32 Ext: 3522, 880-2-9882188 (Direct), 880-1713-093892 (Cell) Fax: 880-2-8810519 E-mail: farhad@icddrb.org URL: http://www.icddrb.org ----- Original Message ----- From: "Molly Cheah" To: ; Cc: "'David Forslund'" ; "Thomas Beale" ; "'Rubin,Ken'" ; "OSHCA Conference participants" Sent: Monday, May 28, 2007 7:52 AM Subject: [participants] Re: [FOSS_health] Re: interoperability - OSHCAcontext > General discussions on interoperability will always bring about varied > views on approaches and different levels of interoperability. > > This discussion on FOSS_health@oshca.org arise from the recent OSHCA > Conference 2007 where the theme is: > "Moving the FOSS Agenda for Health: Setting the Framework for > Interoperability". > > That does not mean that these discussions would not touch on > interoperability between FOSS and proprietary solutions or other past > initiatives. It was unfortunate that David, Klaus and Thomas Beale were > not able to be at the conference. Tim Cook had a presentation on OpenEHR > during the conference. Perhaps he would like to comment on the content of > his presentation that could contribute toward the interoperability issues. > > The conference provided the platform to bring to the participants reviews > on FOSS technologies, issues, applications so that OSHCA can better > prepare to coordinate efforts by its members to collaborate to exchange > data/information between and among current FOSS applications. Though OSHCA > is mindful of other efforts, both in open source and proprietary > environments, OSHCA will focus on efforts that will meet its Vision and > Missions. > > OSHCA's immediate focus resulting from the conference will be a > re-submission of its proposal for a collaborative grant on > interoperability. This is only a small component (preparatory phase - > phase 2) with definitive deliverables within a 6-month period. > > The 3rd phase will then deal with actual transfer of data/information > amongst FOSS applications in test beds. Only projects funded through > OSHCA's funding initiatives will be co-ordinated by OSHCA. OSHCA > encourages and welcomes other initiatives and their presentations at > future OSHCA conferences/workshops. One upcoming opportunity is the GK3 > conference from Dec 11-13 2007 in Kuala Lumpur. See > http://www.globalknowledge.org web-site. > > Many of these discussions may form the content for the methodology of the > grant proposal, while others will be referenced in the proposal, either > for phase 2 or phase 3 project. > > I take the opportunity to copy this e-mail to Thomas and the participants > list for those who had not subscribed to FOSS_health@oshca.org to > participate in discussions on interoperability. > > Rgds, > Molly > > Klaus D Veil wrote: > >>Yes, the HSSP work (a collaboration of HL7 and OMG) has been very >>productive >>and produced results in a very impressive time-frame. >> >>I would encourage members in the FOSS community to review the materials on >>the Wiki and consider participating if possible. >> >>Klaus >> >>-----Original Message----- >>From: David Forslund [mailto:forslund@mail.com] Sent: Monday, 28 May 2007 >>10:53 >>To: Klaus@Veil.net.au; foss_health@oshca.org >>Subject: Re: [FOSS_health] Re: interoperability >> >>Check out http://healthcare.omg.org and http://OpenEMed.org. >>OpenEMed.org implements most of the OMG HDTF specifications from the late >>90s and early 2000's all in open source. These are service-oriented >>specifications specifically designed for interoperability >>and demonstrated to work. The OMG HDTF is working as a joint effort with >>HL7 to update these specifications to current popular technologies and to >>increase their capabilities. You can read more about this work at >>http://hssp.wikispaces.org. It is an open process and, in my opinion, >>should be participated in by those in the FOSS community that are >>interested in interoperability. Participating in this process would >>ensure that open source solutions would be able to >>interoperate with commercial products, this increasing their penetration >>into the broad healthcare market. For many on this list, they've heard >>this >>from me before. There are some participants in the HSSP effort from the >>open source community, but there should be more and it provides some >>interesting targets for demonstrating true interoperability. >>Dave >> >>Klaus D Veil wrote: >> >>>David, >>> >>>Do you want to share more details on the "distributed services for >>>healthcare" that you are referring to? >>> >>>Klaus >>> >>>-----Original Message----- >>>From: foss_health-bounces@oshca.org >>>[mailto:foss_health-bounces@oshca.org] >>>On Behalf Of David Forslund >>>Sent: Monday, 28 May 2007 09:32 >>>To: foss_health@oshca.org >>>Subject: Re: [FOSS_health] Re: interoperability >>> >>>I believe the "intellectually pleasing" approach was accomplished almost >>>a decade ago (or more) but no one seems to understand it or care, which >>>is too bad. "emitting messages" is a fairly archaic and >>> >>"assembly language" >> >>>approach to the problem which keeps software engineers busy but does >>>little to "solve" the problem. Distributed services and standards for >>>them have been around a long time, and people are just >>>starting to understand their value and power. I think they actually >>>simplify the problem considerably, but I appear to be a minority. There >>>are standard mechanisms for discovering what services are available and >>>their capabilities, so that one can connect to a distributed service or a >>>point to point service with equal ease. This is all old stuff that seems >>>to need to be reinvented about every 10 years or so. This is good for >>>full employment of software engineers, but >>> >>not for any benefit to a healthcare consumer. >> >>>Dave >>>Tim C wrote: >>> >>>>On 28/05/07, *Adrian Midgley* >>>> wrote: >>>> >>>> Tim C wrote: >>>> > On 25/05/07, *Tom Jones* >>> >>>> > >>> >> wrote: >>>> > >>>> > I think that the hub and spoke approach is more efficient than >>>> > proliferating >>>> > point to point approaches >>>> > >>>> > >>>> > Yes, that is the received wisdom, but I question whether it is >>>> > actually the case, >>>> >>>> I think if several groups are trying to connect _in the same time >>>> period_ then a lingua franca or even hub and spoke arrangement is >>>> >>more >> >>>> likely to arise and is clearly better. >>>> http://www.defoam.net/writing/4xn.gif >>>> >>>> Given that, new arrivals coming one at a time should find it is >>>> cheaper >>>> to join that, particularly if the lower layers of protocols and >>>> components are FLOSS rather than proprietary, or at least are >>>> published >>>> and gratuit to use. >>>> >>>> However if two orgs need to swap info, they are likely to see a >>>> bilateral special purpose link as cheaper, and they are right. >>>> So later you end up with http://www.defoam.net/writing/4x2.gif >>>> >>>> >>>>In practice, with HL7 v2.x it tends to go like this: >>>>http://members.optusnet.com.au/tchur/interchange.png >>>> >>>> >>>>That is, everyone starts out with what is essentially a point-to-point >>>>interface via a shared message routing hub. Everyone pretends that they >>>>are using a shared format, but in fact they are not to any great degree. >>>>later, a shared format may emerge and everyone endeavours to emit their >>>>messages into that format, but usually additional transformation is >>>>still required in the hub. >>>> >>>>The alternative strategy is to spend a decade or more working on a much >>>>more intellectually pleasing solution, as in openEHR or perhaps >>>>HL7 v3.x. The problem is that it is a hard nut to crack, perhaps too >>>>hard, and people need to get on with exchanging data in the meantime. >>>> >>>>Tim C >>>> >>>>--------------------------------------------------------------------- >>>>- >>>>-- >>>> >> >>_______________________________________________ >>FOSS_health mailing list >>FOSS_health@oshca.org >>http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >> >> >> > > _______________________________________________ > participants mailing list > participants@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/participants > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From christian.heller at tuxtax.de Mon May 28 16:16:12 2007 From: christian.heller at tuxtax.de (Christian Heller) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <465A27F0.5000602@mail.com> References: <003e01c7a0b7$ca611d90$2100a8c0@acerkv> <465A27F0.5000602@mail.com> Message-ID: <200705281016.13423.christian.heller@tuxtax.de> Dave, > I believe the "intellectually pleasing" approach was accomplished almost > a decade ago (or more) but no one seems to understand it or care, which > is too bad. "emitting messages" is a fairly archaic and "assembly > language" approach to the problem which keeps software engineers busy > but does little to "solve" the problem. Distributed services and > standards for them have been around a long time, and people are just > starting to understand their value and power. I think they actually > simplify the problem considerably, but I appear to be a minority. There [..] I think I see the value of HDTF. OpenEMed is an impressive project and I am glad that its source is open. However, changing Interface Definition Language (IDL) interfaces and having to compile them into "Stubs" as soon as new domain knowledge requirements appear (or the standard changes) also keeps developers busy. May be less frequently. Not everyone wants to have an additional ORB process running, just to be able to communicate, but rather rely on their own Remote Procedure Calls (RPC) or Remote Method Invocation (RMI), as it is called in Java. Also, application developers need to convert their domain model into the data structures that have to be provided as parameters to the methods/ procedures/ functions of the IDL interface. So, a conversion is still necessary, just like when translating data into some other (XML-based) exchange format. Nevertheless I support your opinion that Open Source Software (OSS) projects should eventually also provide IDL interfaces to be able to communicate with commercial systems supporting HDTF's: - Person Identification Service (PIDS) - Clinical Observation and Access Service (COAS) - Clinical Image Access Service (CIAS) etc. [..] > interoperability and demonstrated to work. The OMG HDTF is working as a > joint effort with HL7 to update these specifications to current popular > technologies and to increase their capabilities. You can read more > about this work at http://hssp.wikispaces.org. It is an open process [..] Thanks for this link which was new to me. Christian From dalmolin at e-cology.ca Mon May 28 21:10:01 2007 From: dalmolin at e-cology.ca (Joseph Dal Molin) Date: Sun Jan 27 17:55:24 2008 Subject: [participants] Re: [FOSS_health] Re: interoperability - OSHCAcontext In-Reply-To: References: <00cd01c7a0c3$5cb8a4a0$2100a8c0@acerkv> <465A35CC.30208@pc.jaring.my> Message-ID: <465AD4A9.3070306@e-cology.ca> > Information Technology. In this scenario I would like to organize a > community of IT and healthcare professionals to develop healthcare > information systems using FOSS ...my suggestion is that you consider "adapting" one of the existing FOSS health applications rather than developing another one...perhaps you had this in mind already? Joseph Farhad Hussain wrote: > Warm regards from Bangladesh. In the healthcare sector of Bangladesh > computerization is in very early stage. Only big private hospitals in > the capital city Dhaka are computerized. But these information systems > are not talking with each other. Public hospitals are far from using > Information Technology. In this scenario I would like to organize a > community of IT and healthcare professionals to develop healthcare > information systems using FOSS. Keeping OSHCA in mind I think that the > community can actually represent local chapter of OSHCA. After forming > the community we would like to develop a project proposal for submission > to OSHCA in December, 2007. > > Look forward to receiving your comments, suggesstions and advice in this > regard. > > Thanking You. > > Mohammad Farhad Hussain > Manager, Computer Information Services Unit > International Centre for Diarrhoeal Disease Research, Bangladesh (ICDDR,B) > Mohakhali, Dhaka - 1212, > Bangladesh. > Phone: 880-2-8860523-32 Ext: 3522, 880-2-9882188 (Direct), > 880-1713-093892 (Cell) > Fax: 880-2-8810519 > E-mail: farhad@icddrb.org > URL: http://www.icddrb.org > > ----- Original Message ----- From: "Molly Cheah" > To: ; > Cc: "'David Forslund'" ; "Thomas Beale" > ; "'Rubin,Ken'" ; > "OSHCA Conference participants" > Sent: Monday, May 28, 2007 7:52 AM > Subject: [participants] Re: [FOSS_health] Re: interoperability - > OSHCAcontext > > >> General discussions on interoperability will always bring about varied >> views on approaches and different levels of interoperability. >> >> This discussion on FOSS_health@oshca.org arise from the recent OSHCA >> Conference 2007 where the theme is: >> "Moving the FOSS Agenda for Health: Setting the Framework for >> Interoperability". >> >> That does not mean that these discussions would not touch on >> interoperability between FOSS and proprietary solutions or other past >> initiatives. It was unfortunate that David, Klaus and Thomas Beale >> were not able to be at the conference. Tim Cook had a presentation on >> OpenEHR during the conference. Perhaps he would like to comment on the >> content of his presentation that could contribute toward the >> interoperability issues. >> >> The conference provided the platform to bring to the participants >> reviews on FOSS technologies, issues, applications so that OSHCA can >> better prepare to coordinate efforts by its members to collaborate to >> exchange data/information between and among current FOSS applications. >> Though OSHCA is mindful of other efforts, both in open source and >> proprietary environments, OSHCA will focus on efforts that will meet >> its Vision and Missions. >> >> OSHCA's immediate focus resulting from the conference will be a >> re-submission of its proposal for a collaborative grant on >> interoperability. This is only a small component (preparatory phase - >> phase 2) with definitive deliverables within a 6-month period. >> >> The 3rd phase will then deal with actual transfer of data/information >> amongst FOSS applications in test beds. Only projects funded through >> OSHCA's funding initiatives will be co-ordinated by OSHCA. OSHCA >> encourages and welcomes other initiatives and their presentations at >> future OSHCA conferences/workshops. One upcoming opportunity is the >> GK3 conference from Dec 11-13 2007 in Kuala Lumpur. See >> http://www.globalknowledge.org web-site. >> >> Many of these discussions may form the content for the methodology of >> the grant proposal, while others will be referenced in the proposal, >> either for phase 2 or phase 3 project. >> >> I take the opportunity to copy this e-mail to Thomas and the >> participants list for those who had not subscribed to >> FOSS_health@oshca.org to participate in discussions on interoperability. >> >> Rgds, >> Molly >> >> Klaus D Veil wrote: >> >>> Yes, the HSSP work (a collaboration of HL7 and OMG) has been very >>> productive >>> and produced results in a very impressive time-frame. >>> >>> I would encourage members in the FOSS community to review the >>> materials on >>> the Wiki and consider participating if possible. >>> >>> Klaus >>> >>> -----Original Message----- >>> From: David Forslund [mailto:forslund@mail.com] Sent: Monday, 28 May >>> 2007 10:53 >>> To: Klaus@Veil.net.au; foss_health@oshca.org >>> Subject: Re: [FOSS_health] Re: interoperability >>> >>> Check out http://healthcare.omg.org and http://OpenEMed.org. >>> OpenEMed.org implements most of the OMG HDTF specifications from the >>> late 90s and early 2000's all in open source. These are >>> service-oriented specifications specifically designed for >>> interoperability >>> and demonstrated to work. The OMG HDTF is working as a joint effort >>> with >>> HL7 to update these specifications to current popular technologies >>> and to >>> increase their capabilities. You can read more about this work at >>> http://hssp.wikispaces.org. It is an open process and, in my opinion, >>> should be participated in by those in the FOSS community that are >>> interested in interoperability. Participating in this process would >>> ensure that open source solutions would be able to >>> interoperate with commercial products, this increasing their penetration >>> into the broad healthcare market. For many on this list, they've >>> heard this >>> from me before. There are some participants in the HSSP effort from the >>> open source community, but there should be more and it provides some >>> interesting targets for demonstrating true interoperability. >>> Dave >>> >>> Klaus D Veil wrote: >>> >>>> David, >>>> >>>> Do you want to share more details on the "distributed services for >>>> healthcare" that you are referring to? >>>> >>>> Klaus >>>> >>>> -----Original Message----- >>>> From: foss_health-bounces@oshca.org >>>> [mailto:foss_health-bounces@oshca.org] >>>> On Behalf Of David Forslund >>>> Sent: Monday, 28 May 2007 09:32 >>>> To: foss_health@oshca.org >>>> Subject: Re: [FOSS_health] Re: interoperability >>>> >>>> I believe the "intellectually pleasing" approach was accomplished >>>> almost a decade ago (or more) but no one seems to understand it or >>>> care, which is too bad. "emitting messages" is a fairly archaic and >>>> >>> "assembly language" >>> >>>> approach to the problem which keeps software engineers busy but does >>>> little to "solve" the problem. Distributed services and standards >>>> for them have been around a long time, and people are just >>>> starting to understand their value and power. I think they >>>> actually simplify the problem considerably, but I appear to be a >>>> minority. There are standard mechanisms for discovering what >>>> services are available and their capabilities, so that one can >>>> connect to a distributed service or a point to point service with >>>> equal ease. This is all old stuff that seems to need to be >>>> reinvented about every 10 years or so. This is good for full >>>> employment of software engineers, but >>>> >>> not for any benefit to a healthcare consumer. >>> >>>> Dave >>>> Tim C wrote: >>>> >>>>> On 28/05/07, *Adrian Midgley* >>>> > wrote: >>>>> >>>>> Tim C wrote: >>>>> > On 25/05/07, *Tom Jones* >>>> >>>>> > >>>> >> wrote: >>>>> > >>>>> > I think that the hub and spoke approach is more efficient >>>>> than >>>>> > proliferating >>>>> > point to point approaches >>>>> > >>>>> > >>>>> > Yes, that is the received wisdom, but I question whether it is >>>>> > actually the case, >>>>> >>>>> I think if several groups are trying to connect _in the same time >>>>> period_ then a lingua franca or even hub and spoke arrangement is >>>>> >>> more >>> >>>>> likely to arise and is clearly better. >>>>> http://www.defoam.net/writing/4xn.gif >>>>> >>>>> Given that, new arrivals coming one at a time should find it is >>>>> cheaper >>>>> to join that, particularly if the lower layers of protocols and >>>>> components are FLOSS rather than proprietary, or at least are >>>>> published >>>>> and gratuit to use. >>>>> >>>>> However if two orgs need to swap info, they are likely to see a >>>>> bilateral special purpose link as cheaper, and they are right. >>>>> So later you end up with http://www.defoam.net/writing/4x2.gif >>>>> >>>>> >>>>> In practice, with HL7 v2.x it tends to go like this: >>>>> http://members.optusnet.com.au/tchur/interchange.png >>>>> >>>>> >>>>> That is, everyone starts out with what is essentially a >>>>> point-to-point interface via a shared message routing hub. Everyone >>>>> pretends that they are using a shared format, but in fact they are >>>>> not to any great degree. later, a shared format may emerge and >>>>> everyone endeavours to emit their messages into that format, but >>>>> usually additional transformation is still required in the hub. >>>>> >>>>> The alternative strategy is to spend a decade or more working on a >>>>> much more intellectually pleasing solution, as in openEHR or perhaps >>>>> HL7 v3.x. The problem is that it is a hard nut to crack, perhaps >>>>> too hard, and people need to get on with exchanging data in the >>>>> meantime. >>>>> >>>>> Tim C >>>>> >>>>> --------------------------------------------------------------------- >>>>> - >>>>> -- >>>>> >>> >>> _______________________________________________ >>> FOSS_health mailing list >>> FOSS_health@oshca.org >>> http://mailman.oshca.org/mailman/listinfo.cgi/foss_health >>> >>> >>> >> >> _______________________________________________ >> participants mailing list >> participants@oshca.org >> http://mailman.oshca.org/mailman/listinfo.cgi/participants >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > > From forslund at mail.com Mon May 28 21:56:06 2007 From: forslund at mail.com (David Forslund) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <200705281016.13423.christian.heller@tuxtax.de> References: <003e01c7a0b7$ca611d90$2100a8c0@acerkv> <465A27F0.5000602@mail.com> <200705281016.13423.christian.heller@tuxtax.de> Message-ID: <465ADF76.5010801@mail.com> Christian Heller wrote: > Dave, > > >> I believe the "intellectually pleasing" approach was accomplished almost >> a decade ago (or more) but no one seems to understand it or care, which >> is too bad. "emitting messages" is a fairly archaic and "assembly >> language" approach to the problem which keeps software engineers busy >> but does little to "solve" the problem. Distributed services and >> standards for them have been around a long time, and people are just >> starting to understand their value and power. I think they actually >> simplify the problem considerably, but I appear to be a minority. There >> > [..] > > I think I see the value of HDTF. OpenEMed is an impressive project > and I am glad that its source is open. > > However, changing Interface Definition Language (IDL) interfaces and > having to compile them into "Stubs" as soon as new domain knowledge > requirements appear (or the standard changes) also keeps developers > busy. May be less frequently. > You should look at the IDL (not because it is IDL, but because of how it captures this in a way that changes are needed only infrequently). This is a characteristic of any interoperable solution. One needs to use standards that only change infrequently. > Not everyone wants to have an additional ORB process running, just to > be able to communicate, but rather rely on their own Remote Procedure > Calls (RPC) or Remote Method Invocation (RMI), as it is called in Java. > Remember that an "ORB" is really only a naming service to discover where a service is running, which any and every system needs regardless of whether it is CORBA-based. For a corba client to talk to a corba server only requires a reference which can be obtained in many ways, no different from RMI or RPC. There seems to be a lot of misconception of how CORBA works. What CORBA brings to the the table is a more general way of doing RPC's that is language independent. > Also, application developers need to convert their domain model into > the data structures that have to be provided as parameters to the > methods/ procedures/ functions of the IDL interface. So, a conversion > is still necessary, just like when translating data into some other > (XML-based) exchange format. > This is needed for any interoperable solution, in my opinion. I see nothing special other than providing a way of expressing interoperability in a language independent way. Certainly this can be done with XML and Web Services which, I'm sure will be the result of the HSSP work. My major "complaint" about web services so far, is that little concern about interoperability has been considered. Just because you have a web service and I have a web service, doesn't mean we can interoperate. > Nevertheless I support your opinion that Open Source Software (OSS) > projects should eventually also provide IDL interfaces to be able to > communicate with commercial systems supporting HDTF's: > - Person Identification Service (PIDS) > - Clinical Observation and Access Service (COAS) > - Clinical Image Access Service (CIAS) > etc. > These are now almost a decade old and only a few people have bothered to provide these interface implementations. I submit is due to the lack of interest in or understanding of interoperability. Perhaps it is also due to a intellectual barrier, but I don't consider this too seriously, since the complexity of web services is much greater than corba, but parallels it to a large extent (with the major exception of having poor support for objects). Dave > [..] > >> interoperability and demonstrated to work. The OMG HDTF is working as a >> joint effort with HL7 to update these specifications to current popular >> technologies and to increase their capabilities. You can read more >> about this work at http://hssp.wikispaces.org. It is an open process >> > [..] > > Thanks for this link which was new to me. > > Christian > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > From au.jaiganesh at gmail.com Tue May 29 00:48:49 2007 From: au.jaiganesh at gmail.com (Jai Ganesh) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Open Source - Article Watch Message-ID: Dear All, I came across two interesting publications relating to open source recently and thought I will share them with you. They are *A Survey of Quality Assurance Practices in Biomedical Open Source Software Projects* http://www.jmir.org/2007/2/e8/ *Microsoft Wants to 'Kill' Open Source* http://www.businessweek.com/technology/content/may2007/tc20070515_706287.htm?chan=top+news_top+news+index_technology Thank you very much. Regards Jai -- A. U. Jai Ganesh, Enterprise Healthcare Information Systems, Sri Sathya Sai Information Technology Centre, Prasanthi Nilayam - 515134 India. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070528/91ecfa37/attachment.htm From tim.churches at gmail.com Tue May 29 10:37:18 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <465a1209.7f8f2e6c.7e2d.ffffd232SMTPIN_ADDED@mx.google.com> References: <7bb0495c0705271600v4bf2393ese3c6a6779493c545@mail.gmail.com> <465a1209.7f8f2e6c.7e2d.ffffd232SMTPIN_ADDED@mx.google.com> Message-ID: <7bb0495c0705281937u70ecf0b5jfb2ceda48b700813@mail.gmail.com> On 28/05/07, Tom Jones wrote: > > I have heard that dichotomy characterized as the group that "is too busy > to put the steering wheel on the car and is continuing to apply pressure to > the gas pedal" and the group that says "stop the car, we need to design a > steering wheel". The HL7 movement appears to be large enough to contain both > groups! The steering wheel design people are heads down in the RIM, CDA, CCD > etc. and the busy group is churning out more layers of stuff in HL7 v2.n > Yes, perhaps that dichotomy sums it up, and as you say, the two approaches are not mutually exclusive. However, my point is that in a lot of situations and settings, a fleet of bicycles is more appropriate than a car without a steering wheel (HL7 v2.x), or a supercar that is still being designed and built in the workshop (HL7 v3.x, openEHR). Sure you need more people to pedal all those bicycles, but pedalling can be a very healthy thing to do for the economies of developing and transitional countries. And supercars often need perfectly smooth autobahns and freeways to drive on, whereas bicycles can make do with rough dirt tracks if necessary. OK, that's stretching the analogy far enough... Tim Churches ------------------------------ > > *From:* foss_health-bounces@oshca.org [mailto: > foss_health-bounces@oshca.org] *On Behalf Of *Tim C > *Sent:* Sunday, May 27, 2007 4:00 PM > *To:* amidgley@defoam.net; foss_health@oshca.org > *Subject:* Re: [FOSS_health] Re: interoperability > > > > On 28/05/07, *Adrian Midgley* wrote: > > Tim C wrote: > > On 25/05/07, *Tom Jones* > > wrote: > > > > I think that the hub and spoke approach is more efficient than > > proliferating > > point to point approaches > > > > > > Yes, that is the received wisdom, but I question whether it is > > actually the case, > > I think if several groups are trying to connect _in the same time > period_ then a lingua franca or even hub and spoke arrangement is more > likely to arise and is clearly better. > http://www.defoam.net/writing/4xn.gif > > Given that, new arrivals coming one at a time should find it is cheaper > to join that, particularly if the lower layers of protocols and > components are FLOSS rather than proprietary, or at least are published > and gratuit to use. > > However if two orgs need to swap info, they are likely to see a > bilateral special purpose link as cheaper, and they are right. > So later you end up with http://www.defoam.net/writing/4x2.gif > > > In practice, with HL7 v2.x it tends to go like this: http://members.optusnet.com.au/tchur/interchange.png > > > That is, everyone starts out with what is essentially a point-to-point > interface via a shared message routing hub. Everyone pretends that they are > using a shared format, but in fact they are not to any great degree. later, > a shared format may emerge and everyone endeavours to emit their messages > into that format, but usually additional transformation is still required in > the hub. > > The alternative strategy is to spend a decade or more working on a much > more intellectually pleasing solution, as in openEHR or perhaps HL7 v3.x. > The problem is that it is a hard nut to crack, perhaps too hard, and people > need to get on with exchanging data in the meantime. > > Tim C > > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070529/6c22bea9/attachment.html From tim.churches at gmail.com Tue May 29 05:21:25 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <465ADF76.5010801@mail.com> References: <003e01c7a0b7$ca611d90$2100a8c0@acerkv> <465A27F0.5000602@mail.com> <200705281016.13423.christian.heller@tuxtax.de> <465ADF76.5010801@mail.com> Message-ID: <7bb0495c0705281421j3fb81e26x950b4121c659606e@mail.gmail.com> On 28/05/07, David Forslund wrote: > > Christian Heller wrote: > > Dave, > > > > > >> I believe the "intellectually pleasing" approach was accomplished > almost > >> a decade ago (or more) but no one seems to understand it or care, which > >> is too bad. "emitting messages" is a fairly archaic and "assembly > >> language" approach to the problem which keeps software engineers busy > >> but does little to "solve" the problem. Distributed services and > >> standards for them have been around a long time, and people are just > >> starting to understand their value and power. I think they actually > >> simplify the problem considerably, but I appear to be a > minority. There > >> > > [..] > > > > I think I see the value of HDTF. OpenEMed is an impressive project > > and I am glad that its source is open. > > > > However, changing Interface Definition Language (IDL) interfaces and > > having to compile them into "Stubs" as soon as new domain knowledge > > requirements appear (or the standard changes) also keeps developers > > busy. May be less frequently. That was also my initial reaction to CORBA and the HDTF specs. I think it reflects the mindset of those who believe that compile-time binding in programming languages is the only sensible way to work (think C, C++, Java). However, to others who have adopted the mindset of dynamic programming languages (Python, Perl, Ruby, Lua etc), this seems unecessarily cumbersome and like a straightjacket. That dichotomy is also reflected in approaches to Web services, between the WS-* mindset (as promoted by Microsoft and other large IT companies) and the much looser coupling approach of REST, as used mainly be Web start-ups - for an introduction to the ideas behind REST, see http://www.xfront.com/REST-Web-Services.html I know such loose coupling horrifies Dave and many others, but for a lot of sub-domains, it seems to work rather well. Most of the "Web 2.0" sites use a RESTful approach, as do all the Web "mash-ups" that are appearing. Is it useful or sufficient for health applications? That's an open question, but I urge open-source developers to think outside the square of HL7 and even outside the box of CORBA, HDTF and WS-* services and explore RESTful approaches to interoperability, and teh use of Web "microformats" like RSS, ATOM and FOAF, and the use of asynchronous HTTP calls via AJAX machinery in Web (or GUI) apps. They may get you a lot further far more quickly. OK, without much standardisation, but my position is that standardisation should derive from practice, not v-v, and that in many settings it is better to start experimenting and using non-standardised interoperability than it is to get bogged down with having to implement things like the CORBA/HDTF specs, or the nascent HSSP specs (which are not complete, I note) using HL7 v3.x and WS-* for web services. Groan! If you live and work in the richest country in the world which has a health care system that eats 13 or 14% of its huge GDP, then those approaches might be justifiable, but if you live and work in less well-off places, then simpler, more lightweight, faster-to-implement but less standardised approaches might be a better idea in the first instance. Then start to develop appropriate standards for local and regional use on the back of those initial implementations. Leapfrog the mess of of developed-world health IT, don't replicate it. Or at least chose very careful which parts you chose to emulate. > > You should look at the IDL (not because it is IDL, but because of how it > captures this in a way that changes are needed only infrequently). This > is a characteristic of any interoperable solution. One needs to use > standards that only change infrequently. I'm not sure about that. Certainly in public health applications that is not true, nor in a lot of medical research. But I am less and less sure that it is true in clinical medicine as well. openEHR may be the answer to this issue of dynamism, but that remains to be proven in practice, and there are still missing technical parts to the openEHR jigsaw as well as many questions about the ecology of openEHR archetype and template definitions. This is needed for any interoperable solution, in my opinion. I see > nothing special other than providing a way of expressing > interoperability in a language independent way. Certainly this can be > done with XML and Web Services which, I'm sure will be the result of the > HSSP work. My major "complaint" about web services so far, is that > little concern about interoperability has been considered. Just because > you have a web service and I have a web service, doesn't mean we can > interoperate. True, although the RESTful approach typically involves the minimal transformation necessary for a specific purpose. That works when the specific purpose is somewhat constrained. If the aim is to be able to have complete interoperability between one comprehensive clinical application and another, then a more structured approach as embodied by CORBA/HDTF/HL7v3 etc is better. However, I suspect that many real-life (as opposed to thought-experiment) interoperability requirements between applications are a lot more limited than that. Tim Churches > Nevertheless I support your opinion that Open Source Software (OSS) > > projects should eventually also provide IDL interfaces to be able to > > communicate with commercial systems supporting HDTF's: > > - Person Identification Service (PIDS) > > - Clinical Observation and Access Service (COAS) > > - Clinical Image Access Service (CIAS) > > etc. > > > These are now almost a decade old and only a few people have bothered to > provide these interface implementations. I submit is due to the lack > of interest in or understanding of interoperability. Perhaps it is also > due to a intellectual barrier, but I don't consider this too seriously, > since the complexity of web services is much greater than corba, but > parallels it to a large extent (with the major exception of having poor > support for objects). > > Dave > > [..] > > > >> interoperability and demonstrated to work. The OMG HDTF is working as > a > >> joint effort with HL7 to update these specifications to current popular > >> technologies and to increase their capabilities. You can read more > >> about this work at http://hssp.wikispaces.org. It is an open process > >> > > [..] > > > > Thanks for this link which was new to me. > > > > Christian > > _______________________________________________ > > FOSS_health mailing list > > FOSS_health@oshca.org > > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > > > > > > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070529/d064be8f/attachment.htm From tim.churches at gmail.com Tue May 29 05:37:20 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <7bb0495c0705281421j3fb81e26x950b4121c659606e@mail.gmail.com> References: <003e01c7a0b7$ca611d90$2100a8c0@acerkv> <465A27F0.5000602@mail.com> <200705281016.13423.christian.heller@tuxtax.de> <465ADF76.5010801@mail.com> <7bb0495c0705281421j3fb81e26x950b4121c659606e@mail.gmail.com> Message-ID: <7bb0495c0705281437u5851b528n62f0391de8a9f43d@mail.gmail.com> The other type of interoperability which hasn't really been mentioned is the interoperability between the same software application which is deployed in multiple sites. I suspect that in developing and transitional countries, it is that form of interoperability which is the most pressing problem. Using complex mappings to and from HL7 for such purposes may not make a lot of sense when data structures and semantic representations which are native to the application can be shared around far more easily and directly. For example, database replication between different instances of the same software application can be a very effective and effort-effective means of achieving quite extensive interoperability. Sure it is limited to a single type of software, but often that is all that is needed. But with open source, you can mix-and-match. For example, if, say, NetEpi implements database-level replication between sites which are running netEpi, then one way for a SAHANA site to interface to many NetEpi sites would be for the SAHANA site to set up a NetEpi node, have data replicated to it, and then read the required data items directly from their local copy of the NetEpi database. Or vice-versa (NetEpi reads directly from a local replicated SAHANA database). This is possible because a) open-source applications don't hide their internal details like almost all closed-source applications do and b) the marginal cost of setting up an instance of, say, SAHANA or NetEpi is very low - no additional license fees, they can both run on the same hardware and operating system etc.. No message passing at all, except at the application-specific low-level of the database replication. OK, privacy and other concerns may mitigate against that approach everywhere, but it should still be considered in many situations. Tim Churches -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070529/b26f1c95/attachment.html From tim.churches at gmail.com Tue May 29 04:30:45 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <465A27F0.5000602@mail.com> References: <003e01c7a0b7$ca611d90$2100a8c0@acerkv> <465A27F0.5000602@mail.com> Message-ID: <7bb0495c0705281330s2d553272pae86e9692bf93763@mail.gmail.com> On 28/05/07, David Forslund wrote: > > Check out http://healthcare.omg.org and http://OpenEMed.org. > OpenEMed.org implements most of the OMG HDTF specifications from the > late 90s and early 2000's all in open source. These are > service-oriented specifications specifically designed for > interoperability and demonstrated to work. The OMG HDTF is working as a > joint effort with HL7 to update these specifications to current popular > technologies and to increase their capabilities. You can read more > about this work at http://hssp.wikispaces.org. It is an open process > and, in my opinion, should be participated in by those in the FOSS > community that are interested in interoperability. Participating in > this process would ensure that open source solutions would be able to > interoperate with commercial products, this increasing their penetration > into the broad healthcare market. For many on this list, they've heard > this from me before. There are some participants in the HSSP effort > from the open source community, but there should be more and it provides > some interesting targets for demonstrating true interoperability. I actually agree with Dave that a great deal can and should be learnt from the failed CORBA and HDTF efforts of the 1990s - the HDTF specs are very impressive and seem highly workable - we need to think carefully about why they never caught on (seem my reply to Christian message for more thoughts on this). I also agree that open source projects should participate in the HSSP process. What is the procedure for participating, Dave? Do bear in mind that most open source projects have little or no funding and may not have the backing of a formal or large organisation behind them. Tim Churches Klaus D Veil wrote: > > David, > > > > Do you want to share more details on the "distributed services for > > healthcare" that you are referring to? > > > > Klaus > > > > -----Original Message----- > > From: foss_health-bounces@oshca.org [mailto: > foss_health-bounces@oshca.org] > > On Behalf Of David Forslund > > Sent: Monday, 28 May 2007 09:32 > > To: foss_health@oshca.org > > Subject: Re: [FOSS_health] Re: interoperability > > > > I believe the "intellectually pleasing" approach was accomplished almost > a > > decade ago (or more) but no one seems to understand it or care, which is > too > > bad. "emitting messages" is a fairly archaic and "assembly language" > > approach to the problem which keeps software engineers busy but does > little > > to "solve" the problem. Distributed services and standards for them > have > > been around a long time, and people are just > > starting to understand their value and power. I think they actually > > simplify the problem considerably, but I appear to be a minority. There > are > > standard mechanisms for discovering what services are available and > their > > capabilities, so that one can connect to a distributed service or a > point to > > point service with equal ease. This is all old stuff that seems to need > to > > be reinvented about every 10 years or so. This is good for full > employment > > of software engineers, but not for any benefit to a healthcare consumer. > > > > Dave > > Tim C wrote: > > > >> On 28/05/07, *Adrian Midgley* >> > wrote: > >> > >> Tim C wrote: > >> > On 25/05/07, *Tom Jones* >> > >> > >> >> wrote: > >> > > >> > I think that the hub and spoke approach is more efficient > than > >> > proliferating > >> > point to point approaches > >> > > >> > > >> > Yes, that is the received wisdom, but I question whether it is > >> > actually the case, > >> > >> I think if several groups are trying to connect _in the same time > >> period_ then a lingua franca or even hub and spoke arrangement is > more > >> likely to arise and is clearly better. > >> http://www.defoam.net/writing/4xn.gif > >> > >> Given that, new arrivals coming one at a time should find it is > >> cheaper > >> to join that, particularly if the lower layers of protocols and > >> components are FLOSS rather than proprietary, or at least are > >> published > >> and gratuit to use. > >> > >> However if