From hmgoh at amorphous.com.my Fri Jun 1 08:38:31 2007 From: hmgoh at amorphous.com.my (Dr HM Goh) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] RE: [participants] OSHCA-APAMI Collaboration | Moving Forward | In-Reply-To: <004001c7a142$f9e70990$edb51cb0$@com.my> References: <7C4615229DD21546B2399F446305D82A19DBC2@balrog.mrcad.mrc.ac.za> <4653A26F.7000800@pc.jaring.my> <2c9aeb960705221937j2962c4f8r8b111b4ad1743ed9@mail.gmail.com> <004001c7a142$f9e70990$edb51cb0$@com.my> Message-ID: <009101c7a3e5$2e053540$8a0f9fc0$@com.my> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 37714 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070601/b093c8d9/attachment.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41419 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070601/b093c8d9/attachment-0001.jpe From tom.jones at tolvenhealth.com Fri Jun 1 09:29:24 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: <465CADFC.5000208@fnf.com> Message-ID: It's the "looked like" that is the problem. There was not, to my knowledge, true integration of information such that an allergy to a medication registered in the CHCS DoD system triggered an alert if the medication was ordered on the same patient in the VistA VA version. And one can go on from there. The read only visual display was not matched by data re-use across systems Tom -----Original Message----- From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of K.S. Bhaskar Sent: Tuesday, May 29, 2007 3:50 PM To: foss_health@oshca.org Subject: Re: [FOSS_health] Re: interoperability David -- There was a successful proof of concept showing data from both CHCS (DoD version) and VistA (VA version) integrated in the same browser screen using Esi Objects to wrap both flavors of the same application so that they looked like an integrated system. I actually saw a demonstration of this a few years ago. However, even though the technical feasibility was demonstrated, I understand that the rollout was not funded because it was not the officially blessed way to integrate information. Others may have better insight into it, but perhaps too much management can ruin any worthwhile project, as the saying goes... [Yes, I confess to being a manager!] Regards -- Bhaskar David Forslund wrote, On 05/29/2007 06:19 PM: > I agree. The original GCPR project between the VA, DOD and IHS actually > involved the identical software at all the sites, but configured > differently at each site and were totally non-interoperable as a result, > even though much of it was open source (VistA). The HDTF solution > chosen dealt specifically to deal with this problem and it helped in the > solution. HL7 had been used but HL7, itself, doesn't mean systems are > interoperable. Low level database replication is likely to be a poor > interoperability platform in my experience. If one has total control of > all the sites, one might get away with it. Otherwise, forget it. > Mapping XML structures between sites should work well in this situation, > once one knows how to do the appropriate transforms. _______________________________________________ FOSS_health mailing list FOSS_health@oshca.org http://mailman.oshca.org/mailman/listinfo.cgi/foss_health From forslund at mail.com Fri Jun 1 12:48:08 2007 From: forslund at mail.com (David Forslund) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <20070601013026.AC1E717EB1@spf13.us4.outblaze.com> References: <20070601013026.AC1E717EB1@spf13.us4.outblaze.com> Message-ID: <465FA508.1090802@mail.com> It was this full integration that was the goal of the original GCPR project some 7+ years ago. It was well along in a phased development cycle, when the DoD pulled out. The VA continued in a limited way which I think was the basis of this demonstration referred to here. Wrapping them on the screen isn't sufficient. EsiObjects could do much more than this, in my opinion. The biggest issue the GCPR faced was the terminology mapping between the systems (even between DoD systems running the same software). Dave Tom Jones wrote: > It's the "looked like" that is the problem. There was not, to my knowledge, > true integration of information such that an allergy to a medication > registered in the CHCS DoD system triggered an alert if the medication was > ordered on the same patient in the VistA VA version. And one can go on from > there. The read only visual display was not matched by data re-use across > systems > > Tom > > -----Original Message----- > From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] > On Behalf Of K.S. Bhaskar > Sent: Tuesday, May 29, 2007 3:50 PM > To: foss_health@oshca.org > Subject: Re: [FOSS_health] Re: interoperability > > David -- > > There was a successful proof of concept showing data from both CHCS (DoD > version) and VistA (VA version) integrated in the same browser screen > using Esi Objects to wrap both flavors of the same application so that > they looked like an integrated system. I actually saw a demonstration > of this a few years ago. > > However, even though the technical feasibility was demonstrated, I > understand that the rollout was not funded because it was not the > officially blessed way to integrate information. > > Others may have better insight into it, but perhaps too much management > can ruin any worthwhile project, as the saying goes... [Yes, I confess > to being a manager!] > > Regards > -- Bhaskar > > David Forslund wrote, On 05/29/2007 06:19 PM: > >> I agree. The original GCPR project between the VA, DOD and IHS actually >> involved the identical software at all the sites, but configured >> differently at each site and were totally non-interoperable as a result, >> even though much of it was open source (VistA). The HDTF solution >> chosen dealt specifically to deal with this problem and it helped in the >> solution. HL7 had been used but HL7, itself, doesn't mean systems are >> interoperable. Low level database replication is likely to be a poor >> interoperability platform in my experience. If one has total control of >> all the sites, one might get away with it. Otherwise, forget it. >> Mapping XML structures between sites should work well in this situation, >> once one knows how to do the appropriate transforms. >> > > _______________________________________________ > 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 amidgley2 at defoam.net Sat Jun 2 05:28:06 2007 From: amidgley2 at defoam.net (Adrian Midgley) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Open Source - Article Watch Contd... In-Reply-To: <1180587714.6456.38.camel@tchur-laptop> References: <1180587714.6456.38.camel@tchur-laptop> Message-ID: <46608F66.8040005@defoam.net> Tim Churches wrote: > If I were going to choose a 1970 database technology, I'd go for PICK > for elegance, but MUMPS does seem to work Many people who choose a 1970 database technology select an rdbms using SQL. It isn't new. er "Dr. E.F. Codd, an IBM researcher, first developed the relational data model in 1970. In 1985, Dr. Codd published a list of 12 rules that concisely define an ideal relational database, which have provided a guideline for the design of all relational database systems ever since. ?" From drcheah at pc.jaring.my Sat Jun 2 06:58:21 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: OSHCA web?-move to OS Competency Centre In-Reply-To: <20070530072309.5830@smtp.mac.com> References: <465C1A7C.2020904@pc.jaring.my> <20070530072309.5830@smtp.mac.com> Message-ID: <4660A48D.50702@pc.jaring.my> Hi Boh, See reply from OSCC ...... > Dear Molly, > Thanks for your mail. Currently, we do not provide any hosting or > co-location facilities in OSCC as a service. We can, however, explore > possible win-win collaboration between OSCC and OSHCA. > > We will revert back to you on your request after we have discussed > with Madam Tan. > > Thanks. > > Best Regards > Jacob Thomas Jr. > Open Source Competency Centre Malaysia (OSCC) > Lot E302-E304, Enterprise Building 3, > 63000 Cyberjaya, Malaysia. > Tel. 603 83191200, Fax: 603 83193206 > Mobile: +6012-2889276 Boh Heong Yap wrote: >hi Dr. Molly & all, > >re: moving OSHCA server to MAMPU OSCC (Open Source Competency Center). > >this was discussed at OSHCA, I will be glad to participate in a team to >handle this project. I can start by helping facillitate between OSHCA >and the ppl at OS Competency Centre, at least on the technical issues, >HW requirements, HW setup, OS install, network config. etc... . >If you agree, can you do an email intro to the relevant persons? > >Don't know how smoothly this will go tho', from what I understand >speaking to them at the conf., the operations of the OSCC systems are >outsourced to CMG/Dataprep, a commercial Systems House and they did'nt >have any technical person that could explain what thype of >infrastructure they have... (no, I unfortunately did not get to tour >their facillity..) > >I may need someone to help on the beuracratic aspects, official letters/ >docs. contracts. > >I will also need some help with some other aspects... Plone admin in >particular,.. > >Any other volunteers, prefably some local to Kuala Lumpur? > >regds. boh. > > > >>There was problem with the modem to the oshca web portal this morning >>and afternoon. >> >>Streamyx (Telecom Malaysia) had a policy of not revealing the password >>of the modem to our internet connection, but maintain the default >>password of the telecom-supplied modem. We discovered the configuration >>in the modem had been changed.This had been ratified. The web site is >>now working fine. >> >>Rgds, >>Molly >>Visal Doeuk wrote: >> >> >> >>>Dear OSHCA webmaster, >>> >>>Web of OSHCA (http://www.oshca.org/) may down. I can not access this >>>site. Is it work ? Out of this site, where I can find out the >>>prsentations in workshop at KL, Malaysia? >>> >>>Sincerely, >>> >>>Visal >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>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.472 / Virus Database: 269.8.0/819 - Release Date: >>> >>> >>5/26/2007 10:47 AM >> >> >>> >>> >>> >>> >>_______________________________________________ >>participants mailing list >>participants@oshca.org >>http://mailman.oshca.org/mailman/listinfo.cgi/participants >> >> > > > > > > From tw_cook at comcast.net Sat Jun 2 11:41:24 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: OSHCA web?-move to OS Competency Centre In-Reply-To: <4660A48D.50702@pc.jaring.my> References: <465C1A7C.2020904@pc.jaring.my> <20070530072309.5830@smtp.mac.com> <4660A48D.50702@pc.jaring.my> Message-ID: <1180755684.3536.501.camel@oship> Jacob may recall that I addressed this directly with Madam Tan at the OSCC presentation during the tour. Madam Tan agreed to support OSHCA in this way. Regards, Tim Cook On Sat, 2007-06-02 at 06:58 +0800, Molly Cheah wrote: > Hi Boh, > > See reply from OSCC ...... > > > Dear Molly, > > Thanks for your mail. Currently, we do not provide any hosting or > > co-location facilities in OSCC as a service. We can, however, explore > > possible win-win collaboration between OSCC and OSHCA. > > > > We will revert back to you on your request after we have discussed > > with Madam Tan. > > > > Thanks. > > > > Best Regards > > Jacob Thomas Jr. > > Open Source Competency Centre Malaysia (OSCC) > > Lot E302-E304, Enterprise Building 3, > > 63000 Cyberjaya, Malaysia. > > Tel. 603 83191200, Fax: 603 83193206 > > Mobile: +6012-2889276 > > > Boh Heong Yap wrote: > > >hi Dr. Molly & all, > > > >re: moving OSHCA server to MAMPU OSCC (Open Source Competency Center). > > > >this was discussed at OSHCA, I will be glad to participate in a team to > >handle this project. I can start by helping facillitate between OSHCA > >and the ppl at OS Competency Centre, at least on the technical issues, > >HW requirements, HW setup, OS install, network config. etc... . > >If you agree, can you do an email intro to the relevant persons? > > > >Don't know how smoothly this will go tho', from what I understand > >speaking to them at the conf., the operations of the OSCC systems are > >outsourced to CMG/Dataprep, a commercial Systems House and they did'nt > >have any technical person that could explain what thype of > >infrastructure they have... (no, I unfortunately did not get to tour > >their facillity..) > > > >I may need someone to help on the beuracratic aspects, official letters/ > >docs. contracts. > > > >I will also need some help with some other aspects... Plone admin in > >particular,.. > > > >Any other volunteers, prefably some local to Kuala Lumpur? > > > >regds. boh. > > > > > > > >>There was problem with the modem to the oshca web portal this morning > >>and afternoon. > >> > >>Streamyx (Telecom Malaysia) had a policy of not revealing the password > >>of the modem to our internet connection, but maintain the default > >>password of the telecom-supplied modem. We discovered the configuration > >>in the modem had been changed.This had been ratified. The web site is > >>now working fine. > >> > >>Rgds, > >>Molly > >>Visal Doeuk wrote: > >> > >> > >> > >>>Dear OSHCA webmaster, > >>> > >>>Web of OSHCA (http://www.oshca.org/) may down. I can not access this > >>>site. Is it work ? Out of this site, where I can find out the > >>>prsentations in workshop at KL, Malaysia? > >>> > >>>Sincerely, > >>> > >>>Visal > >>> > >>>------------------------------------------------------------------------ > >>> > >>>_______________________________________________ > >>>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.472 / Virus Database: 269.8.0/819 - Release Date: > >>> > >>> > >>5/26/2007 10:47 AM > >> > >> > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>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 -- 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/20070602/2797ace7/attachment.pgp From drcheah at pc.jaring.my Sat Jun 2 14:19:44 2007 From: drcheah at pc.jaring.my (Molly Cheah) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Re: OSHCA web?-move to OS Competency Centre In-Reply-To: <1180755684.3536.501.camel@oship> References: <465C1A7C.2020904@pc.jaring.my> <20070530072309.5830@smtp.mac.com> <4660A48D.50702@pc.jaring.my> <1180755684.3536.501.camel@oship> Message-ID: <46610C00.8020809@pc.jaring.my> Tim, If we need to discuss this, please don't copy your discussions to OSCC or MAMPU? Thanks. Please leave this for me to handle with OSCC/Govt? Rgds, Molly Tim Cook wrote: >Jacob may recall that I addressed this directly with Madam Tan at the >OSCC presentation during the tour. > >Madam Tan agreed to support OSHCA in this way. > >Regards, >Tim Cook > > >On Sat, 2007-06-02 at 06:58 +0800, Molly Cheah wrote: > > >>Hi Boh, >> >>See reply from OSCC ...... >> >> >> >>>Dear Molly, >>>Thanks for your mail. Currently, we do not provide any hosting or >>>co-location facilities in OSCC as a service. We can, however, explore >>>possible win-win collaboration between OSCC and OSHCA. >>> >>>We will revert back to you on your request after we have discussed >>>with Madam Tan. >>> >>>Thanks. >>> >>>Best Regards >>>Jacob Thomas Jr. >>>Open Source Competency Centre Malaysia (OSCC) >>>Lot E302-E304, Enterprise Building 3, >>>63000 Cyberjaya, Malaysia. >>>Tel. 603 83191200, Fax: 603 83193206 >>>Mobile: +6012-2889276 >>> >>> >>Boh Heong Yap wrote: >> >> >> >>>hi Dr. Molly & all, >>> >>>re: moving OSHCA server to MAMPU OSCC (Open Source Competency Center). >>> >>>this was discussed at OSHCA, I will be glad to participate in a team to >>>handle this project. I can start by helping facillitate between OSHCA >>>and the ppl at OS Competency Centre, at least on the technical issues, >>>HW requirements, HW setup, OS install, network config. etc... . >>>If you agree, can you do an email intro to the relevant persons? >>> >>>Don't know how smoothly this will go tho', from what I understand >>>speaking to them at the conf., the operations of the OSCC systems are >>>outsourced to CMG/Dataprep, a commercial Systems House and they did'nt >>>have any technical person that could explain what thype of >>>infrastructure they have... (no, I unfortunately did not get to tour >>>their facillity..) >>> >>>I may need someone to help on the beuracratic aspects, official letters/ >>>docs. contracts. >>> >>>I will also need some help with some other aspects... Plone admin in >>>particular,.. >>> >>>Any other volunteers, prefably some local to Kuala Lumpur? >>> >>>regds. boh. >>> >>> >>> >>> >>> >>>>There was problem with the modem to the oshca web portal this morning >>>>and afternoon. >>>> >>>>Streamyx (Telecom Malaysia) had a policy of not revealing the password >>>>of the modem to our internet connection, but maintain the default >>>>password of the telecom-supplied modem. We discovered the configuration >>>>in the modem had been changed.This had been ratified. The web site is >>>>now working fine. >>>> >>>>Rgds, >>>>Molly >>>>Visal Doeuk wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Dear OSHCA webmaster, >>>>> >>>>>Web of OSHCA (http://www.oshca.org/) may down. I can not access this >>>>>site. Is it work ? Out of this site, where I can find out the >>>>>prsentations in workshop at KL, Malaysia? >>>>> >>>>>Sincerely, >>>>> >>>>>Visal >>>>> >>>>>------------------------------------------------------------------------ >>>>> >>>>>_______________________________________________ >>>>>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.472 / Virus Database: 269.8.0/819 - Release Date: >>>>> >>>>> >>>>> >>>>> >>>>5/26/2007 10:47 AM >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>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 >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>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.472 / Virus Database: 269.8.6/828 - Release Date: 6/1/2007 11:22 AM >> >> From tim.churches at gmail.com Sat Jun 2 20:46:46 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: <465FA508.1090802@mail.com> References: <20070601013026.AC1E717EB1@spf13.us4.outblaze.com> <465FA508.1090802@mail.com> Message-ID: <7bb0495c0706020546h5db23ea2lbd7a197458e82376@mail.gmail.com> On 01/06/07, David Forslund wrote: > > It was this full integration that was the goal of the original GCPR > project some 7+ years ago. It was well along in a phased development > cycle, when the DoD pulled out. The VA continued in a limited way which > I think was the basis of this demonstration referred to here. Wrapping > them on the screen isn't sufficient. EsiObjects could do much more than > this, in my opinion. That is an interesting model for achieving interoperability, quite different to HL7 or other messaging approaches and different to the CORBA approach too, more akin but slightly different to the embedding method I mentioned. Definitely a method applicable to open source health software, though, and one which is hard to apply to closed-source software. The biggest issue the GCPR faced was the > terminology mapping between the systems (even between DoD systems > running the same software). Yes. Has *any* fielded system solved this issue? I don't mean solved it in theory by explicitly binding to terminologies, as openEHR archetypes are designed to do, but solved in practice, with multiple, independently implemented instances of a system demonstrating spontaneous semantic interoperability without additional mapping effort? My guess is "no", because it needs agreed standards for the representation of so many concepts in any sort of reasonably comprehensive system. Just binding to SNOMED CT is not enough, because the use of SNOMED CT per se does not remove ambiguity. Explicit subsets and explicit post-coordination of SNOMED Ct concepts for each data item to be represented is required to avoid all ambiguity, where that is possible. In other areas, the best SNOMED CT can do is (dramatically) reduce he scope for ambiguity, but manual mapping is still going to be required, I strongly suspect. There are still plenty of ways to skin a cat even when using SNOMED CT as its designers intended, and even more if you use it badly. Tim Churches Tom Jones wrote: > > It's the "looked like" that is the problem. There was not, to my > knowledge, > > true integration of information such that an allergy to a medication > > registered in the CHCS DoD system triggered an alert if the medication > was > > ordered on the same patient in the VistA VA version. And one can go on > from > > there. The read only visual display was not matched by data re-use > across > > systems > > > > Tom > > > > -----Original Message----- > > From: foss_health-bounces@oshca.org [mailto: > foss_health-bounces@oshca.org] > > On Behalf Of K.S. Bhaskar > > Sent: Tuesday, May 29, 2007 3:50 PM > > To: foss_health@oshca.org > > Subject: Re: [FOSS_health] Re: interoperability > > > > David -- > > > > There was a successful proof of concept showing data from both CHCS (DoD > > version) and VistA (VA version) integrated in the same browser screen > > using Esi Objects to wrap both flavors of the same application so that > > they looked like an integrated system. I actually saw a demonstration > > of this a few years ago. > > > > However, even though the technical feasibility was demonstrated, I > > understand that the rollout was not funded because it was not the > > officially blessed way to integrate information. > > > > Others may have better insight into it, but perhaps too much management > > can ruin any worthwhile project, as the saying goes... [Yes, I confess > > to being a manager!] > > > > Regards > > -- Bhaskar > > > > David Forslund wrote, On 05/29/2007 06:19 PM: > > > >> I agree. The original GCPR project between the VA, DOD and IHS actually > >> involved the identical software at all the sites, but configured > >> differently at each site and were totally non-interoperable as a > result, > >> even though much of it was open source (VistA). The HDTF solution > >> chosen dealt specifically to deal with this problem and it helped in > the > >> solution. HL7 had been used but HL7, itself, doesn't mean systems are > >> interoperable. Low level database replication is likely to be a poor > >> interoperability platform in my experience. If one has total control > of > >> all the sites, one might get away with it. Otherwise, forget it. > >> Mapping XML structures between sites should work well in this > situation, > >> once one knows how to do the appropriate transforms. > >> > > > > _______________________________________________ > > 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/20070602/8575e3e7/attachment.htm From tim.churches at gmail.com Sat Jun 2 20:53:40 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:24 2008 Subject: [FOSS_health] Open Source - Article Watch Contd... In-Reply-To: <46608F66.8040005@defoam.net> References: <1180587714.6456.38.camel@tchur-laptop> <46608F66.8040005@defoam.net> Message-ID: <7bb0495c0706020553q78ba8da3w53a5b8e20f523aa1@mail.gmail.com> On 02/06/07, Adrian Midgley wrote: > > Tim Churches wrote: > > If I were going to choose a 1970 database technology, I'd go for PICK > > for elegance, but MUMPS does seem to work > Many people who choose a 1970 database technology select an rdbms using > SQL. > > It isn't new. er > > "Dr. E.F. Codd, an IBM researcher, first developed the relational data > model in 1970. In 1985, Dr. Codd published a list of 12 rules that > concisely define an ideal relational database, which have provided a > guideline for the design of all relational database systems ever since. " Yes, but relational DBMSes didn't become popular and widely deployed until the 1980s, and databases which conformed to a standard SQL interface not until the late 1980s, whereas things like network and hierarchical databases, and MUMPS and PICK were very popular and widely used much earlier than that. But in many ways, MUMPS and PICK have a lot in common with XML and object data bases, which are a lot more modern than relational systems. But modernism isn't everything - it is not, per se, good. What is good is what works well in practice. Tim Churches -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070602/a35d3ed4/attachment.html From ks.bhaskar at fnf.com Sat Jun 2 21:35:35 2007 From: ks.bhaskar at fnf.com (K.S. Bhaskar) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Open Source - Article Watch Contd... In-Reply-To: <7bb0495c0706020553q78ba8da3w53a5b8e20f523aa1@mail.gmail.com> References: <1180587714.6456.38.camel@tchur-laptop><46608F66.8040005@defoam.net> <7bb0495c0706020553q78ba8da3w53a5b8e20f523aa1@mail.gmail.com> Message-ID: <46617227.3020700@fnf.com> Tim C wrote, On 06/02/2007 08:53 AM: > On 02/06/07, *Adrian Midgley* > wrote: > > Tim Churches wrote: > > If I were going to choose a 1970 database technology, I'd go for PICK > > for elegance, but MUMPS does seem to work > Many people who choose a 1970 database technology select an rdbms > using SQL. > > It isn't new. er > > "Dr. E.F. Codd, an IBM researcher, first developed the relational data > model in 1970. In 1985, Dr. Codd published a list of 12 rules that > concisely define an ideal relational database, which have provided a > guideline for the design of all relational database systems ever > since. " > > > Yes, but relational DBMSes didn't become popular and widely deployed > until the 1980s, and databases which conformed to a standard SQL > interface not until the late 1980s, whereas things like network and > hierarchical databases, and MUMPS and PICK were very popular and widely > used much earlier than that. But in many ways, MUMPS and PICK have a lot > in common with XML and object data bases, which are a lot more modern > than relational systems. But modernism isn't everything - it is not, per > se, good. What is good is what works well in practice. [KSB] Thank you, Tim, I was beginning to think I would have to give up the wheel, which was invented a couple of years before MUMPS! I joke that the M in XML stands for MUMPS. Regards -- Bhaskar From forslund at mail.com Sun Jun 3 01:52:04 2007 From: forslund at mail.com (David Forslund) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <7bb0495c0706020546h5db23ea2lbd7a197458e82376@mail.gmail.com> References: <20070601013026.AC1E717EB1@spf13.us4.outblaze.com> <465FA508.1090802@mail.com> <7bb0495c0706020546h5db23ea2lbd7a197458e82376@mail.gmail.com> Message-ID: <4661AE44.1060206@mail.com> Tim C wrote: > On 01/06/07, *David Forslund* > wrote: > > It was this full integration that was the goal of the original GCPR > project some 7+ years ago. It was well along in a phased development > cycle, when the DoD pulled out. The VA continued in a limited way > which > I think was the basis of this demonstration referred to > here. Wrapping > them on the screen isn't sufficient. EsiObjects could do much more > than > this, in my opinion. > > > That is an interesting model for achieving interoperability, quite > different to HL7 or other messaging approaches and different to the > CORBA approach too, more akin but slightly different to the embedding > method I mentioned. Definitely a method applicable to open source > health software, though, and one which is hard to apply to > closed-source software. > > The biggest issue the GCPR faced was the > terminology mapping between the systems (even between DoD systems > running the same software). > > > Yes. Has *any* fielded system solved this issue? I don't mean solved > it in theory by explicitly binding to terminologies, as openEHR > archetypes are designed to do, but solved in practice, with multiple, > independently implemented instances of a system demonstrating > spontaneous semantic interoperability without additional mapping effort? I agree. I don't think there is such a thing as "spontaneous semantic interoperability". The major effort of the GCPR was to provide semantic interoperability between essentially identical systems (VA, DoD, IHS) that had different semantics. They were developing a metadata repository that would do the mapping so that each site could see the "foreign" data in their on semantic view. Just running the same system at multiple locations is no guarantee of semantic interoperability. Interoperability takes deliberate effort, but with the right representations of the data and the processes involved, the effort can be made "easier". I think it requires more than data translation, but process translation, too. Dave > > My guess is "no", because it needs agreed standards for the > representation of so many concepts in any sort of reasonably > comprehensive system. Just binding to SNOMED CT is not enough, because > the use of SNOMED CT per se does not remove ambiguity. Explicit > subsets and explicit post-coordination of SNOMED Ct concepts for each > data item to be represented is required to avoid all ambiguity, where > that is possible. In other areas, the best SNOMED CT can do is > (dramatically) reduce he scope for ambiguity, but manual mapping is > still going to be required, I strongly suspect. There are still plenty > of ways to skin a cat even when using SNOMED CT as its designers > intended, and even more if you use it badly. > > Tim Churches > > Tom Jones wrote: > > It's the "looked like" that is the problem. There was not, to my > knowledge, > > true integration of information such that an allergy to a medication > > registered in the CHCS DoD system triggered an alert if the > medication was > > ordered on the same patient in the VistA VA version. And one can > go on from > > there. The read only visual display was not matched by data > re-use across > > systems > > > > Tom > > > > -----Original Message----- > > From: foss_health-bounces@oshca.org > > [mailto:foss_health-bounces@oshca.org > ] > > On Behalf Of K.S. Bhaskar > > Sent: Tuesday, May 29, 2007 3:50 PM > > To: foss_health@oshca.org > > Subject: Re: [FOSS_health] Re: interoperability > > > > David -- > > > > There was a successful proof of concept showing data from both > CHCS (DoD > > version) and VistA (VA version) integrated in the same browser > screen > > using Esi Objects to wrap both flavors of the same application > so that > > they looked like an integrated system. I actually saw a > demonstration > > of this a few years ago. > > > > However, even though the technical feasibility was demonstrated, I > > understand that the rollout was not funded because it was not the > > officially blessed way to integrate information. > > > > Others may have better insight into it, but perhaps too much > management > > can ruin any worthwhile project, as the saying goes... [Yes, I > confess > > to being a manager!] > > > > Regards > > -- Bhaskar > > > > David Forslund wrote, On 05/29/2007 06:19 PM: > > > >> I agree. The original GCPR project between the VA, DOD and IHS > actually > >> involved the identical software at all the sites, but configured > >> differently at each site and were totally non-interoperable as > a result, > >> even though much of it was open source (VistA). The HDTF solution > >> chosen dealt specifically to deal with this problem and it > helped in the > >> solution. HL7 had been used but HL7, itself, doesn't mean > systems are > >> interoperable. Low level database replication is likely to > be a poor > >> interoperability platform in my experience. If one has total > control of > >> all the sites, one might get away with it. Otherwise, forget it. > >> Mapping XML structures between sites should work well in this > situation, > >> once one knows how to do the appropriate transforms. > >> > > > From nandalalx at yahoo.com Sun Jun 3 21:49:55 2007 From: nandalalx at yahoo.com (Nandalal Gunaratne) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <4661AE44.1060206@mail.com> Message-ID: <705840.16318.qm@web58708.mail.re1.yahoo.com> David, "Just running the same system at multiple locations is no guarantee of semantic interoperability." Please explain why this is so, in brief. Thanks Nanda --- David Forslund wrote: > Tim C wrote: > > On 01/06/07, *David Forslund* > > wrote: > > > > It was this full integration that was the goal > of the original GCPR > > project some 7+ years ago. It was well along > in a phased development > > cycle, when the DoD pulled out. The VA > continued in a limited way > > which > > I think was the basis of this demonstration > referred to > > here. Wrapping > > them on the screen isn't sufficient. > EsiObjects could do much more > > than > > this, in my opinion. > > > > > > That is an interesting model for achieving > interoperability, quite > > different to HL7 or other messaging approaches and > different to the > > CORBA approach too, more akin but slightly > different to the embedding > > method I mentioned. Definitely a method applicable > to open source > > health software, though, and one which is hard to > apply to > > closed-source software. > > > > The biggest issue the GCPR faced was the > > terminology mapping between the systems (even > between DoD systems > > running the same software). > > > > > > Yes. Has *any* fielded system solved this issue? I > don't mean solved > > it in theory by explicitly binding to > terminologies, as openEHR > > archetypes are designed to do, but solved in > practice, with multiple, > > independently implemented instances of a system > demonstrating > > spontaneous semantic interoperability without > additional mapping effort? > I agree. I don't think there is such a thing as > "spontaneous semantic > interoperability". The major effort of the GCPR was > to provide semantic > interoperability between essentially identical > systems (VA, DoD, IHS) > that had different semantics. They were developing > a metadata > repository that would do the mapping so that each > site could see the > "foreign" data in their on semantic view. Just > running the same system > at multiple locations is no guarantee of semantic > interoperability. > Interoperability takes deliberate effort, but with > the right > representations of the data and the processes > involved, the effort can > be made "easier". I think it requires more than > data translation, but > process translation, too. > > Dave > > > > My guess is "no", because it needs agreed > standards for the > > representation of so many concepts in any sort of > reasonably > > comprehensive system. Just binding to SNOMED CT is > not enough, because > > the use of SNOMED CT per se does not remove > ambiguity. Explicit > > subsets and explicit post-coordination of SNOMED > Ct concepts for each > > data item to be represented is required to avoid > all ambiguity, where > > that is possible. In other areas, the best SNOMED > CT can do is > > (dramatically) reduce he scope for ambiguity, but > manual mapping is > > still going to be required, I strongly suspect. > There are still plenty > > of ways to skin a cat even when using SNOMED CT as > its designers > > intended, and even more if you use it badly. > > > > Tim Churches > > > > Tom Jones wrote: > > > It's the "looked like" that is the problem. > There was not, to my > > knowledge, > > > true integration of information such that an > allergy to a medication > > > registered in the CHCS DoD system triggered > an alert if the > > medication was > > > ordered on the same patient in the VistA VA > version. And one can > > go on from > > > there. The read only visual display was not > matched by data > > re-use across > > > systems > > > > > > Tom > > > > > > -----Original Message----- > > > From: foss_health-bounces@oshca.org > > > > [mailto:foss_health-bounces@oshca.org > > ] > > > On Behalf Of K.S. Bhaskar > > > Sent: Tuesday, May 29, 2007 3:50 PM > > > To: foss_health@oshca.org > > > > Subject: Re: [FOSS_health] Re: > interoperability > > > > > > David -- > > > > > > There was a successful proof of concept > showing data from both > > CHCS (DoD > > > version) and VistA (VA version) integrated > in the same browser > > screen > > > using Esi Objects to wrap both flavors of > the same application > > so that > > > they looked like an integrated system. I > actually saw a > > demonstration > > > of this a few years ago. > > > > > > However, even though the technical > feasibility was demonstrated, I > > > understand that the rollout was not funded > because it was not the > > > officially blessed way to integrate > information. > > > > > > Others may have better insight into it, but > perhaps too much > > management > > > can ruin any worthwhile project, as the > saying goes... [Yes, I > > confess > > > to being a manager!] > > > > > > Regards > > > -- Bhaskar > > > > > > David Forslund wrote, On 05/29/2007 06:19 > PM: > > > > > >> I agree. The original GCPR project between > the VA, DOD and IHS > > actually > > >> involved the identical software at all the > sites, but configured > > >> differently at each site and were totally > non-interoperable as > > a result, > > >> even though much of it was open source > (VistA). The HDTF solution > > >> chosen dealt specifically to deal with this > problem and it > > helped in the > > >> solution. HL7 had been used but HL7, > itself, doesn't mean > > systems are > > >> interoperable. Low level database > replication is likely to > > be a poor > > >> interoperability platform in my experience. > If one has total > > control of > > >> all the sites, one might get away with it. > Otherwise, forget it. > > >> Mapping XML structures between sites should > work well in this > > situation, > > >> once one knows how to do the appropriate > transforms. > > >> > > > > > > > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > === message truncated === ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ From dalmolin at e-cology.ca Sun Jun 3 22:13:34 2007 From: dalmolin at e-cology.ca (Joseph Dal Molin) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <705840.16318.qm@web58708.mail.re1.yahoo.com> References: <705840.16318.qm@web58708.mail.re1.yahoo.com> Message-ID: <4662CC8E.4020802@e-cology.ca> In both open and proprietary systems users of the same application across multiple organizations usually have the power to add new terminology etc. without some centralized "terminology" standardization process. Joseph Nandalal Gunaratne wrote: > David, > > "Just running the same system at multiple locations is > no guarantee of semantic interoperability." > > Please explain why this is so, in brief. > > Thanks > > Nanda > > --- David Forslund wrote: > >> Tim C wrote: >>> On 01/06/07, *David Forslund* >> > wrote: >>> >>> It was this full integration that was the goal >> of the original GCPR >>> project some 7+ years ago. It was well along >> in a phased development >>> cycle, when the DoD pulled out. The VA >> continued in a limited way >>> which >>> I think was the basis of this demonstration >> referred to >>> here. Wrapping >>> them on the screen isn't sufficient. >> EsiObjects could do much more >>> than >>> this, in my opinion. >>> >>> >>> That is an interesting model for achieving >> interoperability, quite >>> different to HL7 or other messaging approaches and >> different to the >>> CORBA approach too, more akin but slightly >> different to the embedding >>> method I mentioned. Definitely a method applicable >> to open source >>> health software, though, and one which is hard to >> apply to >>> closed-source software. >>> >>> The biggest issue the GCPR faced was the >>> terminology mapping between the systems (even >> between DoD systems >>> running the same software). >>> >>> >>> Yes. Has *any* fielded system solved this issue? I >> don't mean solved >>> it in theory by explicitly binding to >> terminologies, as openEHR >>> archetypes are designed to do, but solved in >> practice, with multiple, >>> independently implemented instances of a system >> demonstrating >>> spontaneous semantic interoperability without >> additional mapping effort? >> I agree. I don't think there is such a thing as >> "spontaneous semantic >> interoperability". The major effort of the GCPR was >> to provide semantic >> interoperability between essentially identical >> systems (VA, DoD, IHS) >> that had different semantics. They were developing >> a metadata >> repository that would do the mapping so that each >> site could see the >> "foreign" data in their on semantic view. Just >> running the same system >> at multiple locations is no guarantee of semantic >> interoperability. >> Interoperability takes deliberate effort, but with >> the right >> representations of the data and the processes >> involved, the effort can >> be made "easier". I think it requires more than >> data translation, but >> process translation, too. >> >> Dave >>> My guess is "no", because it needs agreed >> standards for the >>> representation of so many concepts in any sort of >> reasonably >>> comprehensive system. Just binding to SNOMED CT is >> not enough, because >>> the use of SNOMED CT per se does not remove >> ambiguity. Explicit >>> subsets and explicit post-coordination of SNOMED >> Ct concepts for each >>> data item to be represented is required to avoid >> all ambiguity, where >>> that is possible. In other areas, the best SNOMED >> CT can do is >>> (dramatically) reduce he scope for ambiguity, but >> manual mapping is >>> still going to be required, I strongly suspect. >> There are still plenty >>> of ways to skin a cat even when using SNOMED CT as >> its designers >>> intended, and even more if you use it badly. >>> >>> Tim Churches >>> >>> Tom Jones wrote: >>> > It's the "looked like" that is the problem. >> There was not, to my >>> knowledge, >>> > true integration of information such that an >> allergy to a medication >>> > registered in the CHCS DoD system triggered >> an alert if the >>> medication was >>> > ordered on the same patient in the VistA VA >> version. And one can >>> go on from >>> > there. The read only visual display was not >> matched by data >>> re-use across >>> > systems >>> > >>> > Tom >>> > >>> > -----Original Message----- >>> > From: foss_health-bounces@oshca.org >>> >>> [mailto:foss_health-bounces@oshca.org >>> ] >>> > On Behalf Of K.S. Bhaskar >>> > Sent: Tuesday, May 29, 2007 3:50 PM >>> > To: foss_health@oshca.org >> >>> > Subject: Re: [FOSS_health] Re: >> interoperability >>> > >>> > David -- >>> > >>> > There was a successful proof of concept >> showing data from both >>> CHCS (DoD >>> > version) and VistA (VA version) integrated >> in the same browser >>> screen >>> > using Esi Objects to wrap both flavors of >> the same application >>> so that >>> > they looked like an integrated system. I >> actually saw a >>> demonstration >>> > of this a few years ago. >>> > >>> > However, even though the technical >> feasibility was demonstrated, I >>> > understand that the rollout was not funded >> because it was not the >>> > officially blessed way to integrate >> information. >>> > >>> > Others may have better insight into it, but >> perhaps too much >>> management >>> > can ruin any worthwhile project, as the >> saying goes... [Yes, I >>> confess >>> > to being a manager!] >>> > >>> > Regards >>> > -- Bhaskar >>> > >>> > David Forslund wrote, On 05/29/2007 06:19 >> PM: >>> > >>> >> I agree. The original GCPR project between >> the VA, DOD and IHS >>> actually >>> >> involved the identical software at all the >> sites, but configured >>> >> differently at each site and were totally >> non-interoperable as >>> a result, >>> >> even though much of it was open source >> (VistA). The HDTF solution >>> >> chosen dealt specifically to deal with this >> problem and it >>> helped in the >>> >> solution. HL7 had been used but HL7, >> itself, doesn't mean >>> systems are >>> >> interoperable. Low level database >> replication is likely to >>> be a poor >>> >> interoperability platform in my experience. >> If one has total >>> control of >>> >> all the sites, one might get away with it. >> Otherwise, forget it. >>> >> Mapping XML structures between sites should >> work well in this >>> situation, >>> >> once one knows how to do the appropriate >> transforms. >>> >> >>> > >>> >> _______________________________________________ >> FOSS_health mailing list >> FOSS_health@oshca.org >> > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > === message truncated === > > > > > ____________________________________________________________________________________ > Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. > http://autos.yahoo.com/carfinder/ > _______________________________________________ > FOSS_health mailing list > FOSS_health@oshca.org > http://mailman.oshca.org/mailman/listinfo.cgi/foss_health > . > From amidgley2 at defoam.net Mon Jun 4 04:20:23 2007 From: amidgley2 at defoam.net (Adrian Midgley) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <4662CC8E.4020802@e-cology.ca> References: <705840.16318.qm@web58708.mail.re1.yahoo.com> <4662CC8E.4020802@e-cology.ca> Message-ID: <46632287.7070008@defoam.net> Joseph Dal Molin wrote: > In both open and proprietary systems users of the same application > across multiple organizations usually have the power to add new > terminology etc. without some centralized "terminology" > standardization process. > If they can be, by dint of strenuous efforts at education, proselytising, engineering etc, persuaded and enabled to do so by means of a proper inheritance and sub-classing approach, then some of the effort and vagueness might be reduced. From tim.churches at gmail.com Mon Jun 4 06:19:41 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <46632287.7070008@defoam.net> References: <705840.16318.qm@web58708.mail.re1.yahoo.com> <4662CC8E.4020802@e-cology.ca> <46632287.7070008@defoam.net> Message-ID: <7bb0495c0706031519u50a28c77ue86c2fdd6e95eebd@mail.gmail.com> On 04/06/07, Adrian Midgley wrote: > > Joseph Dal Molin wrote: > > In both open and proprietary systems users of the same application > > across multiple organizations usually have the power to add new > > terminology etc. without some centralized "terminology" > > standardization process. > > > > If they can be, by dint of strenuous efforts at education, > proselytising, engineering etc, persuaded and enabled to do so by means > of a proper inheritance and sub-classing approach, then some of the > effort and vagueness might be reduced. Yes. openEHR, and so some extent the HL7 v3.x people, have proposed (but not completely implemented) technical infrastructure to deal with these problems. There are also a range of mature but rather technically-oriented knowledge management/ontology development tools available for developing shared ontologies and semantic representations, including tools used to build on or subset SNOMED CT. However, I can't help feeling that the technical infrastructure is the trivial part, and that it is the sociological aspects which are the real challenge in achieving long-term, sustainable semantic interoperability between health apps. Many nations have, or are beginning to develop, national health informatics standards which may (or often may not) address some limited aspects of knowedge representation (eg they may specify a specific code set for a particular data item) - see for example teh Australian standards at http://www.saiglobal.com/shop/Script/PortalInformatics.asp but specific code sets are scarce within them - and some countries have national health data dictionaries or knowledgebases - see for example http://meteor.aihw.gov.au/- but these are far from comprehensive with respect to clinical data, although the Australian Meteor facility has good coverage of administratve health data "metadata" (it is not strictly metadata which it contains, it is meta-metadata, but we'll ignore that). However, all these things are at the national level... It seems to me, that with the advent of the SNOMED CT SDO (see http://www.snomed.org/news/documents/snomed_sdo.pdf ) and the prospect of affordable national licenses for developing and transitional countries, that it might be possible to develop at least regional, multi-lingual semantic representation (data encoding) standards for many health sub-domains, based on subsets of SNOMED CT, thus leapfrogging the national-only scope of earlier efforts in some developed countries. Tim Churches -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.oshca.org/pipermail/foss_health/attachments/20070604/9dace377/attachment.htm From forslund at mail.com Mon Jun 4 07:22:35 2007 From: forslund at mail.com (David Forslund) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <4662CC8E.4020802@e-cology.ca> References: <705840.16318.qm@web58708.mail.re1.yahoo.com> <4662CC8E.4020802@e-cology.ca> Message-ID: <46634D3B.6010100@mail.com> Precisely. I have a simple analogy to explain this. Just because a group of people all might use MS Access does not mean that they have any real ability to exchange data between these systems. They are all running the same software, but have probably created their own data dictionaries (tables, etc). The DoD have all used the same software, but weren't required to use a common dictionary or to maintain a common dictionary. This may have changed more recently, but it certainly was the case around the year 2000. I think the VA has done a better job in this regard. Dave Joseph Dal Molin wrote: > In both open and proprietary systems users of the same application > across multiple organizations usually have the power to add new > terminology etc. without some centralized "terminology" > standardization process. > > Joseph > > Nandalal Gunaratne wrote: >> David, >> >> "Just running the same system at multiple locations is >> no guarantee of semantic interoperability." >> >> Please explain why this is so, in brief. >> >> Thanks >> >> Nanda >> > From tim.churches at gmail.com Mon Jun 4 08:09:39 2007 From: tim.churches at gmail.com (Tim C) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <46634D3B.6010100@mail.com> References: <705840.16318.qm@web58708.mail.re1.yahoo.com> <4662CC8E.4020802@e-cology.ca> <46634D3B.6010100@mail.com> Message-ID: <7bb0495c0706031709j5d4c6605wa14441897a6f4724@mail.gmail.com> On 04/06/07, David Forslund wrote: > > Precisely. I have a simple analogy to explain this. Just because a > group of people all might use MS Access does not mean that they have any > real ability to exchange data between these systems. They are all > running the same software, but have probably created their own data > dictionaries (tables, etc). That's not an ideal example, because MS-Access is an application development environment, not a specific application per se. generally, all instances and implementations of a specific applications share the same core tables and schema, although many applications allow a lot of site-specific customisation of the schema, data capture screens, reports etc around the edges. That is a problem, as is the semantic encoding: the use of different code sets at each site, even if each site uses the same software. If there is some overarching or shared governance between sites, then a shared or common "data dictionary" (that is, meta-metadata, codesets etc) can be formulated, but often the only thing in common between different sites is the fact that they are using software from the same vendor (or open-source provider) - and that, as we have been discussing, does *not* mean that interoperability will ensue. Of course, there are only very weak "business drivers" for a hospital in Tegucigalpa and a hospital in Sydney to be able to share or interoperate with respect to clinical information (research information, maybe), but there would seem to be strong business drivers for a hospital in San Salvador or Managua to be able to interoperate at the semantic and syntactic levels with a hospital in Tegucigalpa? And business drivers for interoperability between US military health information systems? Um, what is that old saying about military intelligence? Tim Churches The DoD have all used the same software, > but weren't required to use a common dictionary or to maintain a common > dictionary. This may have changed more recently, but it certainly was > the case around the year 2000. I think the VA has done a better job in > this regard. > > Dave > Joseph Dal Molin wrote: > > In both open and proprietary systems users of the same application > > across multiple organizations usually have the power to add new > > terminology etc. without some centralized "terminology" > > standardization process. > > > > Joseph > > > > Nandalal Gunaratne wrote: > >> David, > >> > >> "Just running the same system at multiple locations is > >> no guarantee of semantic interoperability." > >> > >> Please explain why this is so, in brief. > >> > >> Thanks > >> > >> Nanda > >> > > > > _______________________________________________ > 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/20070604/fc7f5d23/attachment.html From tom.jones at tolvenhealth.com Mon Jun 4 09:22:12 2007 From: tom.jones at tolvenhealth.com (Tom Jones) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <7bb0495c0706031709j5d4c6605wa14441897a6f4724@mail.gmail.com> Message-ID: The Oacis system has a very large implementation in Adelaide. At one time, (and this may still be true), there were substantial Oacis implementations in Toronto (at Sunnybrook) and in Chicago (at the University of Chicago). Imagine the consternation when the users at all three institutions discovered that the Oacis methodology at that time did not include configuring according to a standard information model with standard terminology. Collaborative research across these distinguished teaching institutions just went out the window. Tom _____ From: foss_health-bounces@oshca.org [mailto:foss_health-bounces@oshca.org] On Behalf Of Tim C Sent: Sunday, June 03, 2007 5:10 PM To: foss_health@oshca.org Subject: Re: [FOSS_health] Re: interoperability On 04/06/07, David Forslund wrote: Precisely. I have a simple analogy to explain this. Just because a group of people all might use MS Access does not mean that they have any real ability to exchange data between these systems. They are all running the same software, but have probably created their own data dictionaries (tables, etc). That's not an ideal example, because MS-Access is an application development environment, not a specific application per se. generally, all instances and implementations of a specific applications share the same core tables and schema, although many applications allow a lot of site-specific customisation of the schema, data capture screens, reports etc around the edges. That is a problem, as is the semantic encoding: the use of different code sets at each site, even if each site uses the same software. If there is some overarching or shared governance between sites, then a shared or common "data dictionary" (that is, meta-metadata, codesets etc) can be formulated, but often the only thing in common between different sites is the fact that they are using software from the same vendor (or open-source provider) - and that, as we have been discussing, does *not* mean that interoperability will ensue. Of course, there are only very weak "business drivers" for a hospital in Tegucigalpa and a hospital in Sydney to be able to share or interoperate with respect to clinical information (research information, maybe), but there would seem to be strong business drivers for a hospital in San Salvador or Managua to be able to interoperate at the semantic and syntactic levels with a hospital in Tegucigalpa? And business drivers for interoperability between US military health information systems? Um, what is that old saying about military intelligence? Tim Churches The DoD have all used the same software, but weren't required to use a common dictionary or to maintain a common dictionary. This may have changed more recently, but it certainly was the case around the year 2000. I think the VA has done a better job in this regard. Dave Joseph Dal Molin wrote: > In both open and proprietary systems users of the same application > across multiple organizations usually have the power to add new > terminology etc. without some centralized "terminology" > standardization process. > > Joseph > > Nandalal Gunaratne wrote: >> David, >> >> "Just running the same system at multiple locations is >> no guarantee of semantic interoperability." >> >> Please explain why this is so, in brief. >> >> Thanks >> >> Nanda >> > _______________________________________________ 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/20070603/579256c8/attachment.htm From forslund at mail.com Mon Jun 4 09:27:54 2007 From: forslund at mail.com (David Forslund) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <7bb0495c0706031709j5d4c6605wa14441897a6f4724@mail.gmail.com> References: <705840.16318.qm@web58708.mail.re1.yahoo.com> <4662CC8E.4020802@e-cology.ca> <46634D3B.6010100@mail.com> <7bb0495c0706031709j5d4c6605wa14441897a6f4724@mail.gmail.com> Message-ID: <46636A9A.30508@mail.com> Tim C wrote: > On 04/06/07, *David Forslund* > wrote: > > Precisely. I have a simple analogy to explain this. Just because a > group of people all might use MS Access does not mean that they > have any > real ability to exchange data between these systems. They are all > running the same software, but have probably created their own data > dictionaries (tables, etc). > > > That's not an ideal example, because MS-Access is an application > development environment, not a specific application per se. generally, > all instances and implementations of a specific applications share the > same core tables and schema, although many applications allow a lot of > site-specific customisation of the schema, data capture screens, > reports etc around the edges. That is a problem, as is the semantic > encoding: the use of different code sets at each site, even if each > site uses the same software. If there is some overarching or shared > governance between sites, then a shared or common "data dictionary" > (that is, meta-metadata, codesets etc) can be formulated, but often > the only thing in common between different sites is the fact that they > are using software from the same vendor (or open-source provider) - > and that, as we have been discussing, does *not* mean that > interoperability will ensue. I understand. I was only trying to give an analogy and I've seen this problem first hand.. I know that it easy to change the dictionaries in VistA, which is equivalent to changing the schema in a typical database. Your example is, obviously, much better. And since people don't try to keep the semantics well documented or well organized, the issues you raise are always present. As I said, the DoD, didn't have enough "governance" to regulate this process even between sites. The issue for the DoD was, in my opinion, mismanagement by the company that was doing this (it made them more money). Dave > > Of course, there are only very weak "business drivers" for a hospital > in Tegucigalpa and a hospital in Sydney to be able to share or > interoperate with respect to clinical information (research > information, maybe), but there would seem to be strong business > drivers for a hospital in San Salvador or Managua to be able to > interoperate at the semantic and syntactic levels with a hospital in > Tegucigalpa? > > And business drivers for interoperability between US military health > information systems? Um, what is that old saying about military > intelligence? > > Tim Churches > > The DoD have all used the same software, > but weren't required to use a common dictionary or to maintain a > common > dictionary. This may have changed more recently, but it certainly was > the case around the year 2000. I think the VA has done a better > job in > this regard. > > Dave > Joseph Dal Molin wrote: > > In both open and proprietary systems users of the same application > > across multiple organizations usually have the power to add new > > terminology etc. without some centralized "terminology" > > standardization process. > > > > Joseph > > > > Nandalal Gunaratne wrote: > >> David, > >> > >> "Just running the same system at multiple locations is > >> no guarantee of semantic interoperability." > >> > >> Please explain why this is so, in brief. > >> > >> Thanks > >> > >> Nanda > >> > > > From forslund at mail.com Mon Jun 4 09:30:37 2007 From: forslund at mail.com (David Forslund) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <20070604012332.9E53717EB1@spf13.us4.outblaze.com> References: <20070604012332.9E53717EB1@spf13.us4.outblaze.com> Message-ID: <46636B3D.8050507@mail.com> There apparently was no driving force for these systems to interoperate and it made more money for Oacis to configure each one on its own. It was also pressure, I suspect, from local practitioners who always know best ;-). I believe that money could have been saved if they had thought about interoperability earlier in the process. Dave Tom Jones wrote: > > The Oacis system has a very large implementation in Adelaide. At one > time, (and this may still be true), there were substantial Oacis > implementations in Toronto (at Sunnybrook) and in Chicago (at the > University of Chicago). Imagine the consternation when the users at > all three institutions discovered that the Oacis methodology at that > time did not include configuring according to a standard information > model with standard terminology. Collaborative research across these > distinguished teaching institutions just went out the window. > > > > Tom > > > > ------------------------------------------------------------------------ > > *From:* foss_health-bounces@oshca.org > [mailto:foss_health-bounces@oshca.org] *On Behalf Of *Tim C > *Sent:* Sunday, June 03, 2007 5:10 PM > *To:* foss_health@oshca.org > *Subject:* Re: [FOSS_health] Re: interoperability > > > > On 04/06/07, *David Forslund* > wrote: > > Precisely. I have a simple analogy to explain this. Just because a > group of people all might use MS Access does not mean that they > have any > real ability to exchange data between these systems. They are all > running the same software, but have probably created their own data > dictionaries (tables, etc). > > > That's not an ideal example, because MS-Access is an application > development environment, not a specific application per se. generally, > all instances and implementations of a specific applications share the > same core tables and schema, although many applications allow a lot of > site-specific customisation of the schema, data capture screens, > reports etc around the edges. That is a problem, as is the semantic > encoding: the use of different code sets at each site, even if each > site uses the same software. If there is some overarching or shared > governance between sites, then a shared or common "data dictionary" > (that is, meta-metadata, codesets etc) can be formulated, but often > the only thing in common between different sites is the fact that they > are using software from the same vendor (or open-source provider) - > and that, as we have been discussing, does *not* mean that > interoperability will ensue. > > Of course, there are only very weak "business drivers" for a hospital > in Tegucigalpa and a hospital in Sydney to be able to share or > interoperate with respect to clinical information (research > information, maybe), but there would seem to be strong business > drivers for a hospital in San Salvador or Managua to be able to > interoperate at the semantic and syntactic levels with a hospital in > Tegucigalpa? > > And business drivers for interoperability between US military health > information systems? Um, what is that old saying about military > intelligence? > > Tim Churches > > > > The DoD have all used the same software, > but weren't required to use a common dictionary or to maintain a > common > dictionary. This may have changed more recently, but it certainly was > the case around the year 2000. I think the VA has done a better > job in > this regard. > > Dave > Joseph Dal Molin wrote: > > In both open and proprietary systems users of the same application > > across multiple organizations usually have the power to add new > > terminology etc. without some centralized "terminology" > > standardization process. > > > > Joseph > > > > Nandalal Gunaratne wrote: > >> David, > >> > >> "Just running the same system at multiple locations is > >> no guarantee of semantic interoperability." > >> > >> Please explain why this is so, in brief. > >> > >> Thanks > >> > >> Nanda > >> > > > From hmgoh at amorphous.com.my Mon Jun 4 15:44:30 2007 From: hmgoh at amorphous.com.my (Dr HM Goh) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] Re: interoperability In-Reply-To: <46636B3D.8050507@mail.com> References: <20070604012332.9E53717EB1@spf13.us4.outblaze.com> <46636B3D.8050507@mail.com> Message-ID: <009701c7a67c$308449c0$918cdd40$@com.my> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 37112 bytes Desc: not available Url : http://mailman.oshca.org/pipermail/foss_health/attachments/20070604/ad106191/attachment.jpe From lseldon at alum.mit.edu Tue Jun 5 08:52:30 2007 From: lseldon at alum.mit.edu (Lee Seldon) Date: Sun Jan 27 17:55:25 2008 Subject: [FOSS_health] my summary of discussion In-Reply-To: <4658F0C1.4040100@pc.jaring.my> References: <4658F0C1.4040100@pc.jaring.my> Message-ID: <4664B3CE.4090909@alum.mit.edu> This morning I finally gave up and decided to make a digest of the discussion. So I have pasted together what I find interesting pieces. I still need time to study this and follow up on many of the points. A very very short summary: - FOSS should probably aim for 'functional' interoperability, but might have to start with a 'basic' one. - communications should be based on XML, not on HL7 v2.x. - using XML there already seem to be several (compatible?) initiatives. However, VistA and openMRS both use HL7 v2.x, obviously for reasons of interoperability with existing applications (including themselves). - middleware approaches (CORBAmed, gateways, hubs) have been successful, but seem to have gotten lost or lost favor like much other stuff (good and bad) in IT. Reviving one of them might be more effort than just letting it rest in peace. - the next step could be to agree on an existing XML-based standard, e.g. CCR, HL7 v3 CDA, HL7 v3 messages (of which there exists an extensive list), etc, or join an existing interoperability project, e.g. HSSP HDTF, ... (I am not familiar with these, but somebody certainly is). I can give my opinion of the CCR, HL7 v3, etc ones if desired. Lee DIGEST: 24/5/2007 Wayne Wilson - 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. 24/5/2007 Tom Jones - >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. 24/5/2007 Klaus Veil - 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 24/5/2007 Boh Heong Yap - 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. 24/5/2007 Tim Churches - 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. 25/5/2007 Christian Heller - 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. 25/5/2007 David Forslund - Christian Heller wrote: 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. 26/5/2007 William Lauesen - 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. 28/5/2007 Adrian Midgley - 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 28/5/2007 David Forslund - 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. 29/5/2007 Tim C - >> 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. 30/5/2007 David Forslund - I agree. The original GCPR project between the VA, DOD and IHS actually involved the identical software at all the sites, but configured differently at each site and were totally non-interoperable as a result, even though much of it was open source (VistA). The HDTF solution chosen dealt specifically to deal with this problem and it helped in the solution. HL7 had been used but HL7, itself, doesn't mean systems are interoperable. Low level database replication is likely to be a poor interoperability platform in my experience. If one has total control of all the sites, one might get away with it. Otherwise, forget it. Mapping XML structures between sites should work well in this situation, once one knows how to do the appropriate transforms. Dave Tim C wrote: 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. 30/5/2007 David Forslund - Wayne Wilson wrote: On May 28, 2007, at 5:21 PM, Tim C wrote: 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. Ok, from my some 5 year old perspective, the WEB 2.0 and Identity 2.0 (soon to be followed by 3.0 no doubt :) ) are 'where the most development in Internet based computing' is taking place. It definitely challenges established and standards body approaches to things. My final words to the OMG HDTF, low these many years ago, was to that they had to find a way to start using then emerging (and by induction, any future emerging) approaches such as XML, and follow the old Internet model of starting simple and getting more complex only as needed. You can easily see the this difference by comparing two Internet standards, SMTP (Simple Mail Transport Protocol) and body of PKI work published by IETF. We did include XML concepts into COAS and it actually supports a full super set of XML. I demonstrated this last year with simple handling of the ASTM CCR model without any changes in my backend COAS server. This totally unknown data model at the time of the COAS specification design was rather easily handled by the COAS model because of its flexible design and interface. We could easily run the COAS model over HTTP if we wanted, but I've never seen any good reason to do so. Dave Uptake of SMTP is near universal now, despite such 'extensions' into complexity as MIME while uptake of PKI is still starting and stumbling. While there are always really good engineers and programmers who can take the most complex of standards and use them, my generalization (thus not always true, but mostly true) is that adoption of a standard is inversely proportional to it's complexity. Even then, a simple core communications protocol which is general and can implement specific application protocols on top of it, has been difficult for people to use. One of the Internet's more experienced and seminal protocol engineers, Marshall Rose (SNMP and POP among many others), created just such an abstraction called BEEP. www.beepcore.org . So far, the most significant work built using BEEP has been Apple's Xgrid technology. What I have observed is that people take the fastest and easy route, and for some years now that has been various application protocols built on top of HTTP, including SOAP. For a brief overview of the various components that are being used to build a web services architecture see here: http://en.wikipedia.org/wiki/Web_Services_Protocol_Stack 30/5/2007 Klaus Veil - UK parliamentary briefing document on ICT assistance to developing countries http://www.parliament.uk/documents/upload/postpn261.pdf As a reference for those who might be involved with that, and with UK agencies. 30/5/2007 KS Bhaskar - There was a successful proof of concept showing data from both CHCS (DoD version) and VistA (VA version) integrated in the same browser screen using Esi Objects to wrap both flavors of the same application so that they looked like an integrated system. I actually saw a demonstration of this a few years ago. However, even though the technical feasibility was demonstrated, I understand that the rollout was not funded because it was not the officially blessed way to integrate information. Others may have better insight into it, but perhaps too much management can ruin any worthwhile project, as the saying goes... [Yes, I confess to being a manager!] David Forslund wrote, On 05/29/2007 06:19 PM: I agree. The original GCPR project between the VA, DOD and IHS actually involved the identical software at all the sites, but configured differently at each site and were totally non-interoperable as a result, even though much of it was open source (VistA). The HDTF solution chosen dealt specifically to deal with this problem and it helped in the solution. HL7 had been used but HL7, itself, doesn't mean systems are interoperable. Low level database replication is likely to be a poor interoperability platform in my experience. If one has total control of all the sites, one might get away with it. Otherwise, forget it. Mapping XML structures between sites should work well in this situation, once one knows how to do the appropriate transforms. 1/6/2007 Tom Jones - If your focus is on a single enterprise and you believe that there is no other open source alternative, then you will be willing to spend time working with VistA. This is particularly true if your organization has access to MUMPS programmers and you have limited ambition to develop web-based applications that can be used by a range of existing devices. VistA has been and will continue to be a highly-regarded 20th century solution. If your focus is on community integration across a lot of organizations and you want to take advantage of Java, of the WEB for multi-device deployment (including hand-helds), of the opportunity to evolve a PHR (which is beginning to be an important application in many geographies), of a hosted implementation so that local users need only have access to a browser, and of relational data base technology, then you might want to look at something like Tolven (www.tolven.org) Presumably Tom's comments relate to VistA, which is the subject of the article. > * Home grown information model What is wrong with that if the information model is highly-fit-for-purpose? The idea that one information model can serve all purposes is a pipe dream. > * Reasonable use of standard vocabulary, but no deployment of archetypes/ templates Do you mean openEHR archetypes/templates? An interesting but as yet completely unproven and unevaluated approach. It is absurd to suggest that a system must be based on openEHR (or HL7 v3.x) archetypes and templates in order for that system to have any utility or worth. > * Semantic interoperability is sufficiently limited that, for example, allergy information cannot be exchanged with the DOD That is an implementation/configuration/deployment issue - something to be avoided in future deployments, but not a fundamental problem of VistA itself. Or at least, no more fundamental a problem than exists in every single other available, proven, fielded health information system. > * Application development framework is cumbersome Compared to what? And at least it is free and open-source. There are so many "non-cumbersome" development technologies which are blind alleys or mechanisms for complete lock-in with vendors. But sure, MUMPS is 30 year old technology. But then my car is full of 100 year old technology and I still drive it, and my bicycle is closely based on 150 year old technology but it still works really well. > * No personal health record functionality Is that a showstopper for hospitals or clinics? Very, very few proprietary systems sold here in Oz offer operational personal health record interfaces either. There are several bolt-on or third-party personal health record systems, all of which have problems interfacing with clinical systems to some degree. ... Sort of.... VistA has MyHealtheVet for a personal health record.... and it's just a matter of time before it too becomes available and integrated with WorldVistA EHR.... there is also the option of integrating MyOSCAR. (JDM) > * Most organizations that have deployed clinical information > systems on MUMPS have had to turn to one of the relational > data bases to develop data mining and/or data ware-housing > capabilities. Most organisations of appreciable size who have deployed clinical information systems based on third-normal-form relational structures have had to turn to dimensional data base structures to develop data mining and/or data warehousing capabilities. Both MUMPS and relational systems with large amounts of data both need to move data into a data warehouse which is optimised for reporting and analysis queries. That's life, and it is good practice. And there is no reason why you can't host your reporting and analysis data warehouse in PostgreSQL or MySQL (license costs $0) running on the same Linux server that hosts your GT.M database for VistA. MUMPS and GT.M is sufficiently efficient to leave plenty of horsepower for PostgreSQL or MySQL for the data warehouse even on a modest dual processor machine. So I don't buy your objections to VistA, Tom. But I'd be interested to hear about alternatives (open-source, of course). Tim Churches 1/6/2007 Dr HM Goh - the URL: http://forum.apami.org 01/06/07, David Forslund wrote: It was this full integration that was the goal of the original GCPR project some 7+ years ago. It was well along in a phased development cycle, when the DoD pulled out. The VA continued in a limited way which I think was the basis of this demonstration referred to here. Wrapping them on the screen isn't sufficient. EsiObjects could do much more than this, in my opinion. 3/6/2007 David Forslund - I agree. I don't think there is such a thing as "spontaneous semantic interoperability". The major effort of the GCPR was to provide semantic interoperability between essentially identical systems (VA, DoD, IHS) that had different semantics. They were developing a metadata repository that would do the mapping so that each site could see the "foreign" data in their on semantic view. Just running the same system at multiple locations is no guarantee of semantic interoperability. Interoperability takes deliberate effort, but with the right representations of the data and the processes involved, the effort can be made "easier". I think it requires more than data translation, but process translation, too. From tw_cook at comcast.net Tue Jun 5 10:38:29 2007 From: tw_cook at comcast.net (Tim Cook) Date: Sun Jan 27 17:55:25 2008 Subject: Interoperability Concepts was: [FOSS_health] my summary of discussion In-Reply-To: <4664B3CE.4090909@alum.mit.edu> References: <4658F0C1.4040100@pc.jaring.my> <4664B3CE.4090909@alum.mit.edu> Message-ID: <1181011109.14385.1.camel@oship> Those thinking about interoperability approaches and working on interoperability might be interested in the results of this study. http://content.healthaffairs.org/cgi/content/full/hlthaff.w5.10/DC1#16 On Tue, 2007-06-05 at 10:52 +1000, Lee Seldon wrote: > This morning I finally gave up and decided to make a digest of the > discussion. So I have pasted together what I find interesting pieces. I > still need time to study this and follow up on many of the points. > A very very short summary: > - FOSS should probably aim for 'functional' interoperability, but > might have to start with a 'basic' one. > - communications should be based on XML, not on HL7 v2.x. > - using XML there already seem to be several (compatible?) > initiatives. However, VistA and openMRS both use HL7 v2.x, obviously for > reasons of interoperability with existing applications (including > themselves). > - middleware approaches (CORBAmed, gateways, hubs) have been > successful, but seem to have gotten lost or lost favor like much other > stuff (good and bad) in IT. Reviving one of them might be more effort > than just letting it rest in peace. > - the next step could be to agree on an existing XML-based standard, > e.g. CCR, HL7 v3 CDA, HL7 v3 messages (of which there exists an > extensive list), etc, or join an existing interoperability project, e.g. > HSSP HDTF, ... (I am not familiar with these, but somebody certainly > is). I can give my opinion of the CCR, HL7 v3, etc ones if desired. > Lee > DIGEST: > 24/5/2007 Wayne Wilson - 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. > > 24/5/2007 Tom Jones - >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. > > 24/5/2007 Klaus Veil - 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 > > 24/5/2007 Boh Heong Yap - 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