[FOSS_health] Re: interoperability

[Joseph Dal Molin]

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 <forslund at mail.com> wrote:
> 
>> Tim C wrote:
>>> On 01/06/07, *David Forslund* <forslund at mail.com 
>>> <mailto:forslund at mail.com>> 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 at oshca.org
>>>     <mailto:foss_health-bounces at oshca.org>
>>>     [mailto:foss_health-bounces at oshca.org
>>>     <mailto:foss_health-bounces at oshca.org>]
>>>     > On Behalf Of K.S. Bhaskar
>>>     > Sent: Tuesday, May 29, 2007 3:50 PM
>>>     > To: foss_health at oshca.org
>> <mailto:foss_health at 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 at 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 at oshca.org
> http://mailman.oshca.org/mailman/listinfo.cgi/foss_health
> .
>